Why does your project need a product backlog? Or, does it actually need one, and why? A discussion on Twitter led me to these ponderings... As always, I'm very interested in your thoughts!
agile42 Coach. Visiting Business Influencer and Linchpin. My motto is that of NannyMcPhee: "When you need me, but do not want me, I must stay. When you want me, but no longer need me, then I have to go."
Is A Backlog Waste? Yes. A backlog is inventory and inventory is waste. Simple question.
Does that Help?
No. Depending on your system, some amount of waste will be necessary to be able to keep the flow. Where would you pull stories from if there is no backlog? Directly out of the product owner's mind?
If you need a backlog and how much of it depends mainly on two factors:
- the experience of your team and the product's stakeholders (including the level of trust between them), a.k.a. the maturity of your system, and
- the context your development works in, the requirements come from and the product is shipped to.
Fixed Price, Fixed Scope, New Team, New Client
Let's start with the worst case. You have a freshly assembled team, new to agile. A new client who has not done agile before as well asks for a fixed price on a fixed scope, they hand over a specification...
If you're not experienced in doing this and haven't been responsible for such a project before, there's a very simple advice: don't do it. I don't say you couldn't win, but investing your time elsewhere is probably a pretty neat option in this case.
But if you have... You rewrite the spec as a list of stories (please don't bother asking me how to do that, it's neither easy nor simple nor anything you'd really want to be paid for). You prioritise and estimate, make an educated guess (insert your experience here) on the hours per story point and the velocity to calculate the price and the date. Make an offer.
Forget those numbers once you got the contract. Seriously. Erase them from memory. Start developing and keep the client up to date on progress. Involve her in reviews and planning, she might like it... You might still fail. Did I say this was not easy?
You can't do this without a backlog for one single reason: you need a number for your offer. One might argue that just guessing the outcome of the process would lead to a number of equal value, well, go ahead. Predicting the future is not for the faint at heart, if you bet your money on it. It might not make much of a difference, but you might be more confident (and your stakeholders might be, too).
You'll probably have to report progress on such a project, and this approach makes that easy (reporting the process that is, not finishing on time etc).
Ongoing Product Development, Experienced Team, Mature Stakeholders
Now for the best case. This is short: there is no need for a backlog at all. Your product owner might prepare some storys (put a WIP limit on that) she's currently most interested in, the team can go ahead and estimate, discuss and have them ready for sprint (WIP limit that, too). If you need higher-level, long-term planning, define a (temporary) goal and pull (WIP-limit again) Capabilities, Features (MMFs) and Stories from these (it's a wide board, but this is the ideal world, right?). Extend your board to the right, too (behind Done). Put Features (Completed), Capabilities (Realised) and Goals into those columns to make ROI visible.
You might ask: what about our customer requests? What about our bugs? The valuable input from Marketing? Seriously, forget it. Steve Jobs doesn't care about customer requests, neither should you. Ideal world, remember? You're building an awesome product, your customers love you. Do you know why? Because they don't buy what you do, they buy why you do it!
No need for a backlog. Watch Simon Sinek explaining the importance of Why over What:
If you want to become courageous enough to build your product without a backlog, read Rework. It's awesome.
Establish a Pull Circle
Let's step back from the examples and become a bit more general, and pragmatic. Liz Keogh, genius wordsmith of BDD fame, explains software development as a pull circle. This is what you should aim at (and make compromises if your world is not ideal).
- Create a compelling vision for your product.
- Pull goals from that vision (probably one at a time, maybe one per release).
- Pull capabilities you want your product to have from that goal. Bring in the developers to be realistic. Prioritise. Aim for the simplest possible addition that adds value to your product.
- Pull features from the one or two most important capabilities. Discuss them with your users if you want to.
- Let the developers pull stories from these features. Size them appropriately. If you want to sprint, do that.
- Let the testers pull scenarios from the stories.
- Write the code, test it, and ship it.
Repeat as you see fit.
(My summary of the process is not taken from the InfoQ post, but from the amazing BDD tutorial Liz did at XP2011 in Madrid last week. The details may differ, the general idea is the same.)
Do as you see fit. Be courageous. Erase what you don't need, and seriously consider your backlog to be wasteful. Even if you don't go ahead deleting it, you might use it more sensibly and value it even more than before... So it goes.
Please share your thoughts and experiences in the comments!