Warning: The following post might provoke a mild aneurism to some scrum purists.
Don’t you love a nice, clean and deep Product Backlog, filled only with strong user stories tightly linked to clear business objectives and estimated by business value and story points? As an Agile coach working with large organization with even larger challenges, I don’t usually have that luxury. And If I do, I don’t believe it! The amount of stuff that needs to be done to ship out quality software is astronomical and never ceases to amaze me. So of course the “Definition of DONE” is equally immense.
The definition of DONE
Creating and shipping software in large organizations involves tasks and deliverables that go beyond straightforward testing, coding and releasing. To get all this work out into the open, I ask teams to focus on a couple of “juicy” user stories and ask them to identify ALL that needs to be completed to get this product in front of the user. We might get something like this:
And the list goes on and on…
Teams are then challenged to get everything done within a user story. Of course this is impossible. The best the team (and the supporting organization) can do for now is to complete some DONE items at the sprint, milestone, release or project level (see fig.1)
Figure 1
The further away we are from the user story level, the more nervous I get. At the beginning of an Agile transition, I can live with that as long as we identify these “non-story DONEs” as debt and we manage it appropriately. I don’t judge or question any of the DONE items (ok, maybe I do, but not out loud) But I do want to the team and the organization to clearly see the sheer volume of overhead and offer them some kind of tool to start cutting out the fat.
This tool will be…The Product Backlog.
The team will manage this debt by adding non-functional work items in the Product Backlog. In other words, all DONE items not included within a user story will become a work item in the Backlog. If the team’s initial estimate is 4 sprints for a release, then those sprint-level DONE items will appear four times. This continues with milestone, release and project DONE items. This makes for one polluted Backlog – And that’s ok…For now! As you can imagine, this can double the scope of the project.
A product backlog can go from this:
To this:
What does it mean?
Based on the team’s velocity, it’ll probably take 4 to 5 sprints complete the project and not 2 – That is, if nothing changes. It means that it won’t take 15 points to produce $26,000 in business value but at least 33. Nasty!
It can also show an organization that went through a chaotic period and decided to structure all that is I.T. into a defined process; a normal reaction. Over design and over documentation is heavy and expensive, but it’s still better than the anarchy of the early years.
Finally, it means we need find the correct balance for this project and organization.
What do we do?
If the organization is polluted, so shall be the Product Backlog – Deal with it! No really, you need to deal with it.
The Product Backlog can’t remain in that state. It’s needs to be filled, almost exclusively, with items that deliver business value. That said, don’t hide the real work that currently needs to be done or simply take that work into consideration by inflating story points. It needs to be out there, for all to see. We want to provoke a sense of urgency and change.
All the $0 business value items are now action items, things that a Scrum team and the surrounding organization need to deal with now. If we can’t eliminate an item all together (Ex.: Code document? – I mean come on!), then we need to find out how we can reduce the effort needed to get it done. We need to reduce waste and those dollars signs might motivate those upper management folks to get things moving.
This approach is provocative but in many large organizations, shock and awe is often required to encourage change. If a Product Owner and ScrumMaster can clearly show that it costs $1 to create $0.25 of value, I promise you that something will happen.
So between a polluted Product Backlog and a clean one that doesn’t show us the full picture, I choose the former…For now! 😉