Should I assign Story Points to bugs?
- Mike Cohn posted a blog post on assigning Story Points to bugs. Here is his post:
I hold a different view, actually based on his writings and definitions.
I'd be interested in other folks' thoughts. I know we've litigated this before, but thought since Mike recently posted it on it that it's worth discussion.
In Scrum, Should I assign Story points to bugs?
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 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 solutions to the "should I assign story points to bug fixes" are also 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.
1. 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.
2. I encourage teams to then "inspect and adapt" on sizing bugs, just as they would for User Stories.
3. 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!
Although, this is not Twitter. I really want to do a +1.>>It (and the length of this thread) is a great illustration of why I recommend that teams not get too wrapped up in estimation. They start looking for numerical precision, and that starts consuming the energy that could be put toward accomplish goals.
Echoes my thoughts completely. Won't have been able to put it better myself.