This post has been deprecated.
Essentially, if you look at the Bradley Bug Chart on the replacement post, any bug that ends up on the Product Backlog(Legacy Bug, “Not a Bug”, “New Feature”, or “Deferred Bug”, etc), should be assigned story points, and any bug that ends up on the Sprint Backlog should not be assigned story points.
[old deprecated article below --V]
First a definition.
Bug – Any behavior of the system that either violates an acceptance test, or is unacceptable system behavior that cannot practically be covered by an acceptance test(for example, aesthetics issues, or legacy bugs). Another way of saying this is any behavior that is inconsistent with previously well understood requirements and/or acceptance tests.
This definition is useful when deciding whether something is a bug or an enhancement.
So, I break bugs down into the following three categories and assign points as follows:
1) Legacy bugs
I define a “legacy bug” as any bug that was introduced prior to the team adopting Scrum. Those go on the backlog as user stories and are estimated in points and prioritized by the PO.
2) Scrum Era bugs
Any other “bug”, introduced since adopting Scrum, is fixed within one sprint of it’s discovery(this sprint or next) and no story points assigned, unless both the PO and dev team agree to defer the bug beyond that next sprint(Deferred bugs). If either the dev team or PO chose to have the bug fixed this sprint or next, then the bug appears as a task for the sprint, and is estimated in hours.
3) Deferred bugs
These go on the backlog and are estimated in Story Points and prioritized by the PO.
While this logic is somewhat complex, all other decent solutions to the “should I assign story points to bug fixes” are also fairly complex, and usually have much larger risks of bad effects.
Some subscribe to this theory that “bugs can’t be well estimated” theory. I don’t. Here’s why.
- I encourage team members to take some time to investigate a bug, up to an hour to estimate a bug that appears to be nasty. This helps reduce estimation inaccuracies.
- I encourage teams to then “inspect and adapt” on sizing bugs, just as they would for User Stories.
- If the team still can’t be terribly accurate after a few iterations, then I would probably just encourage them to spend more time investigating nasty bugs to obtain a better estimate — this would be an extreme situation in my opinion(very low quality product). Note that they can only investigate for an estimate, the time is not meant to spend diagnosing or fixing the bug.
Some teams try to set aside a set amount of time each sprint for fixing bugs, and assign story points to that effort. I also don’t agree with that, as I feel it hinders transparency and makes it too easy for teams to sweep new bugs under the rug. “We’ll have time to fix this later in the bug fixing sprint or in the bug fixing time-box next sprint.”
Having said all of the above, while PO’s are certainly allowed to prioritize bugs into sprints, the dev team is also allowed to pick any bug it feels needs fixing (whether it be on the backlog or not), and bring that into the sprint as a task (they gain no story/velocity points for this, regardless of whether the bug was on the backlog or not). Only the dev team can decide how much product backlog to bring into a sprint, so if they decide to spend ~ 50% of their sprint bug fixing things not prioritized by the PO, so be it, but it will be visible because their velocity will be lower.
So, in short, Legacy and Deferred bugs can be fixed either:
a) When they are prioritized into the sprint because the PO perceives business value gained (story points added into velocity), OR
b) When they are brought into a sprint by the dev team because the dev team perceives value, and no story points are added into velocity as a result of fixing these bugs.
According to Mike Cohn’s User Stories Applied :
“…the developers will estimate how much work they’ll be able to do per iteration. We call this velocity…”
Further if you measure velocity in User Story Points, then each User Story must be
“…valuable to either a user or purchaser of a system” (also from Cohn’s book)
So, velocity is meant to be an estimate of a team’s iteration capacity to deliver User Stories that are of value to users and stakeholders outside of the dev team. I believe the above strategies that I describe do just that.
I could be wrong though, and I encourage others to let me know if they think I am!
© 2010, 2011 Charles Bradley. All Rights Reserved.
About the author:Mr Bradley is an experienced Scrum Coach, Certified ScrumMaster, and Certified Professional ScrumMaster I. In addition to his Scrum credentials, Mr. Bradley is also a highly capable, full lifecycle experienced, software development team lead that prefers XP for good engineering practices. He is Sun Certified in Java, and has 13 years of experience in J2EE application development across all tiers. More recently he has also picked up some good C# experience as well. In his spare time, he enjoys driving his wife crazy by talking about Scrum, especially when he refers to his “honey do” list as his “personal backlog” and asks his wife to prioritize her requests. He lives in Denver, Colorado, and he is easily found on LinkedIn.