Comments on: Scrum defined in under 10 minutes

By: John McCaffrey

John McCaffrey — Wed, 06 May 2009 05:44:06 +0000

new post here
http://www.pathf.com/blogs/2009/05/bugs-cant-be-estimated

By: Agile Ajax » Bugs can’t be estimated » Pathfinder Development

Agile Ajax » Bugs can’t be estimated » Pathfinder Development — Wed, 06 May 2009 05:37:13 +0000

[...] an earlier post about the benefits of Agile and Scrum, I made a statement that bugs by their nature are not the [...]

By: Olivier Gourment

Olivier Gourment — Thu, 29 Jan 2009 16:15:41 +0000

The zero-bug policy is implied by the definition “Done”: is it “Done” if it doesn’t work? However, this raises the question of what is a bug? You should ask yourself “does the bug get in the way of the user doing what he has/wants to do”, or “is the bug preventing to attain the story’s goals?”. This may include aesthetics if we are talking about the home page of a corporate public web site. So, the definition of a bug is contextual. In summary, if you know you will have to fix the bug in the next 0 to 60 days, then you should better tackle it now that the code is fresh. And better put too much energy (including pair programming, brainstorming meetings and refactoring) than too little.
Finally, in this context, one understands why the problem of estimating a bug is moot (and I agree that accurately estimating a bug is almost equivalent to fixing it!).

By: PM Hut

PM Hut — Wed, 28 Jan 2009 13:51:31 +0000

I was trying to figure out why you’re saying that bugs can’t be estimated. It’s just a matter on when and how you handle these bugs. It also depends on whether the bug is critical or not. If not, it can just go to a bugtracking tool. If it is, then there are several flavors of doing it, if the bug is of high complexity, it can go to the product backlog, if not, it can also be sent to the bugtracking too, but handled asap.