BT

Should You Assign Story Points To Bugs?

by Dan Puckett on Jan 17, 2011 |

When migrating an existing project to Scrum, you are often faced with a backlog of unfixed bugs from the pre-Scrum era. What's the best way of working down this backlog of bugs? Mike Cohn recommends assigning story points to these old bugs and prioritizing them in each sprint by using the normal Scrum workflow:

My usual recommendation is to assign points to the bug fixing. [...] We are able to see how much work the team is really able to accomplish but also able to look at the historical data and see how much went into the bug-fixing story each sprint. Knowing this can be helpful to a team and its product owner. For example, imagine a situation in which the product owner is considering suspending bug fixing for the next six sprints in order to add a valuable different feature into a release. If we know that the team's full historical average velocity was 25 but that 5 points went to bug fixing each sprint, we know that suspending bug fixing for the next six sprints will result in 30 (6*5) more points of new functionality.

In addition to sprint prioritization strategy recommended by Mike Cohn, Charles Bradley also wants more options for the development team to fix bugs within the sprint:

[...] 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.

Jack Milunsky makes an important distinction between how to handle legacy bugs versus bugs written within the current sprint:

The only time one should assign story points to bugs is for legacy bugs. There is definite value in this for Product Owners—specifically quality in this case. Bugs found and fixed during the sprint should not be assigned any story points as this will affect the velocity in such a way as to provide false sense of how fast the team is moving.

Should we assign story points to fixing a bug that was written under Scrum rules but has somehow escaped the boundaries of its sprint? That is, what about bugs found in user stories that were declared "done" in some previous sprint? Ron Jeffries writes:

If somehow a story slips out and then a defect is found, that story has already been recorded in velocity. Velocity is artificially high. What should we do? One possibility is to reduce our progress bar by that amount, and insert that story back when and if it is fixed. That might be more accurate but it is not necessary.

All we do, instead, is count only the stories done next time. Time spent fixing the broken one does not count. Our progress line drops by one story, starting now. The line was artificially high for a while, but now it is back in line.

Note that the defect may take less time than it took to build the story wrong, or it may take more. Either way, the time necessary to complete the story correctly, and the number of stories completed, is back in balance with respect to that story. No estimation is required, no rationalizing about why we should treat what is obviously waste as if it were somehow a good thing.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Bugs Deserve Points, Sort Of by Greg Willits

I buy into the premise that working on bugs should reflect a drop in velocity. In effect, a bug is incomplete work. It is a debt owed to the points completed and velocity. It is useful to know that it took X weeks to complete Y story points (bugs and refactors included as part of the normal course of getting work completed). The original value representation of points is a valid, useful metric.

However, I also want to know what the percentage of "rework" is. How much effort is spent fixing things post-facto? That's a useful number to know too. And, when it comes to adding bugs to an iteration, you have to know if it is a big one or a little one just like a story.

So from that standpoint, IMO, bugs should be estimated and should be assigned points--in effect treated like a story. However, all the software tools or manual spreadsheet tools we use to track projects should be collecting those points in a different bucket so we can alayse the first-pass quality of the team, and the rework trends. What's the average rework volume? Are we getting sloppier as time goes on, or as the code gets more complex? How do we know that? What's the average deay in discovering rework? Days, weeks? We can know that if we track the rework trends.

-- gw

Re: Bugs Deserve Points, Sort Of by Pat Leamon

This is agile so, sure, track your defects and see if you can get anything useful from that metric. If nothing useful shows up, stop tracking them.

I'd keep the metric separate from story points until your tracking shows that they are equivalent and should be combined.

Legacy (only) bugs deserve story points... by Assaf Stone

In my opinion, bugs that escaped the sprint they were created in should be recorded, and the work required to fix them should be prioritized like any other story / task.
This accomplishes several goals:
First, the PO is knows what the bugs are, and how expensive fixing them will be, and can (must) prioritize each bug against the remaining stories.
Second, by recording the bugs' SP cost, you can extrapolate the cost of moving at a certain velocity; No more bosses "wondering" why velocity is plummeting.
Third, the unrealistic onus of developers to crank features as if there are no bugs, and fix the bugs as if there are no new features.

It is important to remember that the task load of the team should be transparent to the PO, and as he/she is ultimately responsible for the delivery, the team should not (have to) decide whether to work on a committed story or on something else, that may or may not be important; it is not the team's job to decide what is important.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT