Is the bug to the left a large bug or a small bug? It looks HUGE to me! Well, in reality it is probably between .5 and .75 inches long. Not really a very big bug at all. Why do we care? Because trying to size the fixing of software “bugs” is at least as hard as figuring out how big this bug is!
When I teach an Agile or Scrum course someone will almost always ask a question like “How do you handle bug fixes in iterations or sprints?” When I ask “How do you want to handle them?” we get into a pretty interesting discussion. Most people say something similar to “We should prioritize them with the user stories, size them like we do user stories and then see what fits into each iteration.” I usually smile and ask any developers if they know ahead of time how long it will take to fix a defect. They ALWAYS say “Sometimes.” And THAT is the problem!
How can you actually determine the size of fixing something which is broken in an unknown way? I tell people in my classes I only know two sizes for defect fixes: 1) Trivial because I already know what’s broken and how to fix it, or 2) Infinite because I have no idea what’s broken or how to fix it! If those are the only two sizes available to us how can we possibly put them into iterations effectively?
I have found one effective solution to be the use of Kanban techniques for defect fixing. I don’t want to get into what Kanban is or isn’t and when it should or shouldn’t be used, so I’ll just lay out what I have seen be effective for a number of teams:
- Prioritize the defect list. This is NOT done in the context of user stories, but separately. The list is prioritized however the Product Owner says it should be prioritized.
- The team and Product Owner decide on how much effort (time) should be used each iteration to work on defects. Hopefully this is not a large amount, but it might be for teams which have large numbers of defects in a legacy system.
- The team determines when the defect fixing time occurs and how they do it. Most effective is to put a gate or two in place on the defects. For example, gate 1 may say the developer needs to know within 2 hours if the defect is going to take more than a day to fix. If so, then put it off until a discussion can take place with the Product Owner. Gate 2 may be after a day if the defect is not fixed perhaps another discussion needs to take place. However the gates are set up (if they are) the defects are worked in priority order.
- Limit the number of bug fixes being worked at one time to a very small number. If you don’t do this you will have each developer working on at least one defect and run the serious risk of none of them getting fixed before the iteration or sprint ends!
This 3 step approach allows the team to work on defects in priority order while allowing a set amount of time to be spent on the defects. The amount of time spent can be changed as needed to address the business needs of the organization at any point in time.
The downside of this is no one can tell a stakeholder something like “that bug will be fixed by date X” or “we’ll knock out X bugs this iteration.” Saying anything like that is a lie anyway, so this shouldn’t be a big issue. I say these statements are lies under the assumption the defects are non-trivial.
How else have you managed a defect backlog that has been effective? I’d love to have more proven techniques for people to experiment with!
Until next time my clients will be Making Agile a Reality® by using sizing only when appropriate!
