Agile‎ > ‎

Should Bugs Be Sized?

posted Apr 9, 2015, 12:59 PM by Anjuan Simmons   [ updated Jul 21, 2016, 6:41 PM ]
A user in one of the Agile Linkedin groups I follow posed this question:

Could some one provide me the information about story pointing bugs? Is it right way? or when can we?

Here's my answer:

Here are the principles I apply to this:
  • Nothing goes into the sprint until its Ready. So, user stories should be properly detailed and sliced as needed. They should also be sized. If you slice the stories properly, you should get an idea of other similarly sized stories in other parts of the application and also get an idea of how many bugs you can expect. So, the size of the story should be relative measure of getting it to done (code complete, code reviewed, debugged, etc.). Also, the Definition of Ready should include any information about the bug history of that part of the application that should be recognized by the Development Team.
  • The Definition of Done should include everything needed to get a story in a state that could be released to the customer. This includes the fixing of bugs.
  • Nothing is worked on unless its in the Sprint Backlog. If, in the act of creating a feature, one or more bugs are generated, then the point value of the story should reflect fixing the bug.
  • So, nothing enters the sprint unless its Ready. Also, nothing leaves the sprint until its Done. Bugs should be taken care of through Readiness preparation and Doneness completion.