http://www.peterlyons.com/problog/2010/09/agile-bugs/

In case anyone is interested in open source, here is a link to my current thoughts on the topic: http://wiki.apidesign.org/wiki/Bugzilla
I’ll be glad to hear some comments.

To me velocity is simply the amount you are capable of delivering in a sprint. If the velocity is 5, you can do 5 points in a sprint. I used it for sprint planning and thats it. It doesn’t say whether I am making progress or not. To me its like the speedometer in a car: 50km/h is the speed. You could well be driving in circles.

Story point is just the size. Do bugs have a size? Sure.

To measure progress, I would stick in a business value amount or something similar. Give bugs a BV of 0. Then we can use that to see if the BV is burning down or not. Figure out the BV velocity to see if you are only fixing bugs or actually making progress.

The question is: are we mixing up the two and making story points and velocity do double duty in measuring both size and value?

The thing I am not sure that we agree on is how often we should expect this should happen. If we’re getting a lot of bug reports in “Done” stories, it suggests to me that something is broken and we should stop to discover why that is.

Going back to the twitter thread: if we give bugs 0 velocity points, and discover that we’re spending all our time fixing bugs, that will make it excruciatingly visible that we’re spending all our time patching up gaps in the original stories and not making progress toward new capabilities. And that should trigger the discussion about “how come we [as the whole team, including the PO] can’t seem to ship anything without getting a whole bunch of bug reports?”

Getting velocity “credit” for those bugs will make folks feel better about doing all that work, but it is an illusion. Organizational anesthesia. It masks the harsh truth that we’re not making progress, or our progress is significantly slowed, because of rework. I’d rather have the velocity numbers show the truth about the results so we can deal with it rather than tell us a pleasant fiction that makes everyone feel good about their effort.

We do a story, its accepted and deployed. In deployment a user does something unanticipated that causes it to crash. PO decides that its a rare combination so we’ll do it later.

By your definition this would be a new story, not a bug, but that doesn’t sound right to me.

Did it violate the PO expectation when it was accepted? No. Does it violate the current expectation? Yes. We need to allow our understanding of the system to evolve and decide against that.

IMHO, its a bug if it violates the current, most up to date understanding of the system.

In 2002-2004, I took the lead-tester role in a small biotech startup, bringing protein prediction software out of Bill Goddard’s lab at Caltech (Pasadena, California). For eighteen glorious months of Extreme Programming joy, we turned out products at a rate rivalling the best of the Scrum teams that John Sutherland’s been (rightfully) raving about the past year or so.

We had two defects escape the team room. Both times, the development team had misunderstood the Product Owner (Joe) on a subtle but (later-discovered) crucial point. This was prime learning on everyone’s part, even the guys who developed the algorithms in the first place. (That indirectly led one of our researchers to find several SARS anti-viral drug candidates one lunch hour, but that’s going off into the weeds ….)

Our attitude matched yours. If it didn’t meet Joe’s expectation, I didn’t mark it as DONE and the team won’t let me if I tried. I also served as tracker, so this was hard-data feedback, the best type.

We did accumulate about four dozen nit-picky details by the end, mainly polish stuff like typo corrections and some items which really should have gone into the backlog. Most of it got taken care of at opportune times, like waiting for the other pairs to finish up so we could all go to lunch.

We moved so fast in part because we chose to resolve all “bugs” not track them and lug them forward. Had we not, we’d have closed shop in a few months, and none of these multi-million-dollar products would exist today.

Think that’s small beer?

I applied exactly the same attitude and approach at Hewlett Packard, late 1990s, integrating HP/UX. Cleaned out a year-long backlog of bugs and issues, fixed all causes of inflow into that backlog, and got onto similar immediate footing, all within nine months.

This had been scheduled and budgeted for “twelve months minimum” on the critical path. Crafting and providing HP/UX at the time required several thousand developers and hundreds of non-technical supporters full-time.

My most pessimistic estimates for the direct cost savings this attitude gave HP runs $6.5m. That year, this represented a half-cent per share of additional earnings — a 0.2% boost to earnings per share of a Fortune 20 company.

Fiduciary duty should require this attitude, I’d argue.

Elisabeth responds:

However, it might not be necessary to test it through the UI. Sometimes it looks like a UI thing because that’s how the issue was found, but it’s something that can be tested below the GUI. And in that case, I advocate automating the test at the lowest level possible. (Making too many of the automated tests go all the way through the GUI leads to all kinds of problems.)

btw, this is why we have “acceptance sessions” every week where the PO (along with the rest of the team) gets to see the newly coded story (not done, but where the developer thinks they’ve coded everything) and then makes comments or adjustments, e.g., “change that wording”, “that total looks wrong”, etc. Sometimes we’ll track those comments as bugs (really, stories to be done later), or the developer will just go fix it/them after the session.