≡ Menu
Pawel Brodzinski on Software Project Management

How Big Is Your Backlog?


Several months ago Mary Poppendieck visited Krakow, where I live, to give a speech. Mary delivered one of her standard pieces on lean software development, which wasn’t really an epiphany for me. However one thing sticks with me until today, so after all it looks like Mary did pretty good job.

It was about backlog size and Mary’s point was it should be as small as possible, but of course not smaller than it still makes sense. I can’t recall the exact example now but it was like you should have about the same number of items in backlog as you have in ready-ready or todo stage. In terms of our Kanban board it would be like maximum of 3 features in backlog.

The reasoning was that keeping big backlog effectively means you may have huge lead time (a time elapsed from putting the card on the board to moving it to done-done stage) which is an obvious case of waste. As we all know waste is bad so we should have possibly few items in backlog.

Now, the reason I still have this part of the presentation in the back of my head is I completely disagree with that. Well, I won’t say the bigger the backlog is the better, but I’m against setting up a goal of having tiny backlog.

Actually backlog is like Santa Claus bag for me. It can contain millions presents and still looks pretty handy. The cost of adding an item to the backlog is very low. How much time you could have wasted while writing several word on a sticky note?

Where’s the trick then? If you add too many items to backlog it will become clutter and product owner have tough time dealing with it and making good decisions what to do next. And clutter is like waste. And that proves Mary’s point.

But it is still product owner’s decision either to throw something away or keep it on board.

There is of course a plus side too. Make it easy to add things to backlog and you will have a container for all features you forgot during initial development or those you should build as soon as there is a free developer. You will have a reminder which functions were omitted and which important changes you discussed on design meeting a couple of months ago. You will have a better understanding of the product’s current shape.

Decision what to do next made by product owner may be more difficult but it will likely be better.

If you ask me this is fair trade-off. I choose flexibility over making decisions easier. And I definitely don’t call content of our backlog a waste. Well, I don’t, unless sticky notes fall down from the board and cleaning lady throw them into the bin.

By the way I hope to start this discussion with Mary at AgileEE where we both have presentations. Do consider visiting Kyiv in October. This is going to be great conference.

And how big is your backlog?

Advertisement: Help to create Study on the Image of the Project Management Profession. Complete the survey. The survey is run by my fellow blogger – Ciprian Rusen from Corporate Geek.


in: kanban, project management

7 comments… add one

  • Josh Nankivel September 6, 2010, 6:22 pm

    I agree with you Pawel, I almost choked when I read the bit about having just a few items in the backlog. One of the things I am loving about Kanban is the ability to prioritize upcoming tasks in such a visual way. To me, the backlog should be about a month worth of work in the future as a general guideline with perhaps some “planning packages” that have not been decomposed into tasks yet for longer timescales. Doing it this way I have found Kanban is still very easy and intuitive to use.

  • Pawel Brodzinski September 7, 2010, 12:45 am


    I must say I see the point of having small backlog, even though I don’t agree with it. Actually if you have just few things in backlog and there are no others that’s perfectly fine. The thing I don’t agree with is enforcing small backlog size.

    By the way: I’m not 100% sure but I believe it was Joel Spolsky who said that they don’t really need to track users requests (aka maintain big product backlog) since if something is really important it would pop up many times and everyone would know it by heart anyway. I can’t say I fully agree with this one either but there’s some point.

    Much depends on a product you build. If you work directly with end-users you will have different type of feedback than if you build hosted backoffice solution. In the latter case users won’t be coming to say which feature they need and which they think you screwed, so you need a place to store this data – a backlog. And if your product is big enough the backlog either will be big or not really valuable.

    There are of course some tricks to keep backlog pretty tidy even if it is big, but that’s the subject for another post.

  • Federico Zuppa September 8, 2010, 3:42 am

    I believe what Mary is saying is that ‘projects/chunks of work’ should be small, right? Minimizing the time it takes from concept to cash increases the ROI. Having an item a long time in the backlog, increases the lead time and decreases the ROI. I guess another way of seeing it is it’s better to have 3 1/month releases than a big 3/months release. Of course, any feature needed for a particular product needs to be maintained somehow (I don’t think she talks about this anyway)

  • Pawel Brodzinski September 8, 2010, 4:29 am


    I don’t agree. Actually size of backlog doesn’t have to (and often isn’t) interrelated with size of features. We can have 1-month releases, actually we have more like 10-day releases, and still have big backlog.

    Another thing is I don’t buy a ROI argument. I don’t see “I” part. Putting item in the backlog doesn’t require any investment. Investment starts when you really start working on a feature, which is one of reasons why we keep our ready-ready (or todo) column short.

    On a side note: this is actually argument against forcing backlog to be small. I agree that chunks of work should be reasonably small.

  • Kasia September 9, 2010, 2:13 am


    Jestem studentką III roku Zarządzania w Wyższej Szkole Zarządzania Ochroną Pracy w Katowicach. Obecnie jestem w trakcie pisania pracy licencjackiej pt. “Wpływ rozmowy oceniającej na motywację pracowników”. Znalazłam Pana wpis na forum odnoścnie tej właśnie tematyki. Poszukuje firm, które oceniają pracowników właśnie za pomocą rozmowy w celu przeprowadzenia badań ankietowych niezbędnych do napisania pracy.
    Byłabym wdzięczna za wszelkie informacje na temat kontaktu z takimi firmami.


  • Federico Zuppa September 9, 2010, 5:05 am

    I see from the point of view of a person that has an idea (concept) until that idea is materialized (cash). The longest this takes, the more expensive it is (or the longest this user doesn’t have this functionality). Lean cares about flow. In fact, the ideal is having the idea and being able to build it immediately (i.e. have a wip of 1 item). ROI decreases cause time is money and work in progress (items in the backlog) is waste (and costs money as you need to maintain it, right?)

  • Pawel Brodzinski September 10, 2010, 3:14 am


    I guess it becomes an academic discussion, but I’m not convinced. First, I know few systems where dependency between delivering new feature and getting money is direct.

    Second, I don’t see how a week of development of widget foo is more expensive in a month from now than the same week of development now. I pay the same for the work being done. I don’t pay anything for maintaining sticky note on a whiteboard for that month.

    Third, since I don’t pay for keeping a feature in the backlog, at least as long as I don’t start preparing it for development I don’t really see a difference in ROI. Time is money but bear in mind it is not discussion whether to implement widget foo or do nothing. It is a discussion whether to implement widget foo or function bar. And which one would bring us more value.

    Yes, it is a trade-off discussion but actually in terms of ROI keeping a widget foo in backlog may be reasonable as it would bring us $5 while function bar would yield $25.

Leave a Comment