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!

19 May 2011
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?


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

  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!

Subscribe to new blog posts

Did you find this article valuable? To be promptly noticed of new blog posts by agile42 you can subscribe to our notification system via email.

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

Scrumtisch October 2017

Scrumtisch Berlin October 2017


Scrumtisch Berlin: August 22nd, 2017

August 2017 meeting of the Berlin Scrum User Group, facilitated by agile42 coaches Noel Viehmeyer and ...


Certified Agile Leadership comes to Vancouver

First part of the Scrum Alliance Certified Agile Leadership (CAL) program will be available in Vancouver ...


Survival Tricks for Remote Developers

Video and slides of the talk presented by Alessio Bragadini at PyCon 8 conference in Florence, ...


Sponsoring Agile Africa

agile42 sponsors Agile Africa 2017 in Johannesburg, 21-22 August