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)
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:
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! 😉
18 juin 2010
I am a big fan of putting the dollars and cents out there for the decision makers. I am not a big fan of putting process out there with no assigned value for them to hack up.
I put this information in the sprint backlog as tasks for a story. They can still see it and the work it takes. It looks like you are hand holding your team and asking management to mess with your process by putting all of the details in there, many of which management won’t understand.
For instance, I’ve heard (too many times), « we’ll do our own QA » from the business stakeholders trying to bring down cost. Clearly not understanding the task and trivializing the work with serious consequences.
Be careful what you ask for…
17 juillet 2010
Thanks for your comment!
Yes! I understand and agree with your concerns. A coach needs the tread carefully when pushing a team to identify ALL that needs to be done to create a clearer release plan and estimate the time needed to get this QUALITY product in front of the client. Yep, all hell can break loose.
But I do firmly believe in customer collaboration with the dev team and creating mutual respect and appreciation for the work to be done. If stakeholders what to cut corners, fine – our responsibility is to expose the real cost of doing so.
« management to mess with your process by putting all of the details in there, many of which management won’t understand. »
Again, within a collaborating team, the product owner will work with the other teams members, gain an understanding of the work needed, challenge team and come up with a win-win the solution.
8 septembre 2010
Merci pour ce post!
Je suis entièrement d’accord avec ton approche et je l’encourage fortement.
La seule différence, dans mon cas, est que je traduis les éléments non-business (définition) en heures plutot qu’en points.
La réflexion que je me fais est que lorsque l’équipe ou les stakeholders regardent le backlog ou le « velocity chart », ils ne confondent pas les éléments « business » avec les éléments « non-business ». Par exemple, si l’organisation fait en sorte que la définition de DONE est de plus en plus lourde et que l’équipe doit beaucoup travailler sur celle-ci pour compléter une story, ca devrait avoir un impact négatif en diminuant significativement la vélocité de l’équipe (donc sa capacité à produire de la valeur d’affaires).
Le but est de rendre cet impact « highly visible for everyone »!
4 octobre 2010
I agree with you.
Beyond making visible the amount of work, I think it also shows that the development team can’t deliver the product alone, especially in large organization. But it is this team which is committed…
So I have some questions… quite opened 🙂
– How can we preserve the commitment of the team with such non-INVEST stories?
– How can we deal with these external dependances? (i agree with you when you say « polluted » : it seems to be a smell at the organizational level…)
– What is the impact on sprint reviews? How are non-functional stories validate?
– In its definition of done, should the team accept to have items on which it has no or few control? (user training for instance)
ok, i guess your answer is… « it depends! », don’t you? 🙂
8 octobre 2010
Merci pour ton commentaires.
Pour ma part, les éléments « business » comptabilisés par la valeur d’affaires n’a rien à voir avec les Story Points. J’encourage les équipes de réalisations de comprendre leur vélocité via les points, mais aux gens d’affaires de se soucier du ROI, c-a-d, le nombre de points requis pour compléter $x valeur d’affaires.
8 octobre 2010
Thanks for your comment!
Preserving the commitment of the team with non-INVEST stories is not an issue in my experience. But team commitment can be deeply affected when dealing with Backlog items that depend heavily on outside help (External dependencies). If those external dependencies can’t be integrated within the team, I still hold the team responsible for getting these things done. It’s a tough sell sometimes.
And there are other downsides to doing this, such as:
• The Product Backlog becomes harder to manage
• The Product Owner won’t be able to prioritize by him/herself (but the PO never should)
• Item estimation is more difficult
• Once polluted, the Backlog can become a cesspool of technical stuff if all non-INVEST items are not dealt with quickly and iteratively .
But the advantages and changes this approach encourages far outweigh the downsides:
• Forces transparency and visibility
• Creates a great platform for discussion
• Helps the Product owner get a better understanding of non-business items
• Encourages constructive criticism
• Great stuff for Sprint Retrospectives
• Encourages all dependencies to integrate the team in some way and commit
• Helps identify and control overproduction and inventory