blogs.conchango.com

I think that having a "bug backlog" is a great idea.  But how do you get the product owner to assign relative priorities of bugs against features?  Otherwise the team will simply plough ahead with features until the bug debt exceeds a sprint and so you'll end up with an occasional "bug-fixing sprint".

I'm not so sure about a separate backlog for bugs as this removes the “single view of the truth” but I do like the concept of a view that shows whether the team are within a Sprint of a releasable product. My personal preference would be to ensure that the impact of the bugs is visible at the Product Backlog level (i.e. the PB items with bugs are not “Done” and have an estimate of time against them). In this way the Product Burndown graph will continue to show the team their overall progress that includes any bug debt. To assess whether the team are within a Sprint of a releasable product simply provide a report that shows the total work outstanding against all product Backlog items that have been started.

Colin: so your version of "Done" includes "no known bugs", which means that it's not a very stable state (i.e. PB items wiil tend to oscillitate between Done and Not Done as bugs are discovered and fixed).  It's also possible that low impact bugs will accumulate over time, which would then result in more and more PB items being Not Done even though they may be acceptable to the business.

Definnition of 'DONE' as I'm sure you know is core to Scrum. I brought up the point about Product Backlog Items not done and rolling over at Mike Cohn's Certified Scrum Master training -- and yes in his expert view there was a consequence that if a Product Backlog Item is not 'done' then it carries over to the next Sprint, albeit with less tasks. HOWEVER the size of the Product Backlog Item doesn't change as a result of this process (it might change due to needing to reestimate but that's another story).

This, Mike agreed, does mean that when it comes to release planning you get bumps -- one of the exercises was 'If you can't fit A, B, and C but end up doing 'quite a lot' of C, you still presesnt C in entirety for the next Sprint.

My subsequent experience at Conchango suggests there some detail around this that really helps me and our Product Owner. What my experience leans on is that there is very often an elaboration / breakdown of Product Backlog Items into smaller ones as the sprint progresses -- and that this is done while maintaining the tenet of representing some clear business value. Let's take an example similar to one I had in my project:

We started with Product Backlog Item (PBI):

'As a web user I want to use a mortgage calculator so that I can get an illustration of the costs involved'.

After design and user experience and stuff it becomes clear half way through the sprint that it doesn't fit into the Sprint, i.e. it won't be DONE. Traditional software processes say 'delay it so it fits' which is of course in violation of the basic tenet of fixed time, fixed quality, variable scope, and Generally A Bad Thing (why? -- business users start whining they've not seen anything, they're not part of the journey, they then have less empathy if Things Vary From Plan).

So I (myself as Scrum Master) sit down with the Product Owner and the tech lead and we come to an agreement that we split it into 2 smaller stories:

'As a web user I want to use a mortgage calculator so that I can get an illustration of the costs involved'

BECOMES

1. 'As a web user I want a noninteractive illustration of typical mortgage payments so that I can get an indication of the costs involved'

2. 'As a web user I want to be able to interactively change the values used in the illustration of typical mortgage payments to more closely match my personal circumstances'.

So the Product Backlog Item was SPLIT -- but as a result, using good ol' User Stories, rewriting the requirements in 2 bits focused the 2 elements well. In my Product Backlog I employ simple traceability so that when a Product Backlog Item was split I refer to the original parent Product Backlog Item for verification later.

In regards to what 'done' is -- yes you're right, in essence what you're saying is that there are TWO KINDS OF DONE (sorry for upper case -- there is no styling support in comments here ... ):

'Potentially releasable' DONE

'Releasable' DONE

(I use 'releasable' because you don't ship web software really, you release it. Small, insignificant tweak. )

I think this is a good thread; perhaps we should pick the essence of it up in the next Conchango Agile Community of Best Practice?

Last November I attended the 2006 Scrum Gathering in Minneapolis along with fellow Conchangoens Colin