Blog

Is A Backlog Waste?

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!

On
19 May 2011
In
Scrum
Tags
backlog, bdd, lean, pull, waste

    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?

    Context

    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.

    Examples

    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).

    1. Create a compelling vision for your product.
    2. Pull goals from that vision (probably one at a time, maybe one per release).
    3. 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.
    4. Pull features from the one or two most important capabilities. Discuss them with your users if you want to.
    5. Let the developers pull stories from these features. Size them appropriately. If you want to sprint, do that.
    6. Let the testers pull scenarios from the stories.
    7. 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.)

    Bottom Line

    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!

    Discussion 1 Comment

    Great article! In addition: in the section "establish a pull circle" it strikes me just how much the product backlog is used in communication (with stakeholders, clients, developers, management ext). I guess if you have a product backlog but are not using it in some way to communicate with people about your product, there is something wrong. So at the one hand see the backlog as waste so it doesn't become a goal in itself and on the other hand use it to communicate and visualize your product development. Menno Jongerius (Product Owner at PAT)

    Comments are closed.

    Comments are closed.

    Comments have been closed for this post.

    Latest entries

    Our Scrum training calendar for Seattle, Houston, Denver, Vancouver

    Scrum certifications and training in the United States and Canada for our North America Fall/Winter season ...

    0 Comments

    Scrumtisch September 2014

    29. September 2014 - Scrumtisch in Berlin

    0 Comments

    Welcome Turkey!

    agile42 is expanding with activities in Turkey and last month we explained in Istanbul the vision ...

    0 Comments

    Thirteen cities, eleven European countries!

    Scrum certifications and Kanban trainings in eleven different countries for our European Fall/Winter season 2014-15

    0 Comments

    Dhaval Panchal joins agile42

    Certified Scrum Coach and Trainer Dhaval Panchal is latest addition to the US coaching team of ...

    0 Comments