No Backlog Policy

I hate Product Backlogs’ unrestrained tendency to grow, get messy and unmaintainable.

Photo: Grant Hutchinson on Flickr

How Backlog Was Supposed To Work

Ideally, a Product Backlog should give the whole team a clear roadmap on work to be done.

I remember times when I actually believed this is really possible, even with a huge Backlog, but in practice in every project I worked on I struggled with keeping the Backlog up-to-date, prioritised and consistent.

Then, thanks to Roman Pichler (see Top Ten Product Backlog Tips for example) I understood that the Product Backlog requires a lot of care (well, the same way like codebase does). This includes:

  • Finding right wording for user stories
  • Writing acceptance criteria for stories
  • Managing stories on various level of detail, decomposing them when necessary
  • Removing(!) no longer valid entries from the list
  • Rewriting other ones
  • Getting stories estimated
  • Prioritising
  • and that is probably not the end of the list.

All of this done regularly!

Woow, that is a lot of work!


In practice, most of Product Owners or people responsible for Product Backlog (including myself) do not perform most of these tasks regulary, because the only really important horizons (at least in agile/lean approach) are:

  1. This iteration/week
  2. Upcoming release or other important date, usually within a couple of weeks from now

This means that what actually matters is on the top of the Backlog. All other stories are… well… you can either say “less important at the moment” or, I believe more correctly, “waste”.

No… Well, Maybe

I am a huge fan of “Start With No” approach.

Photo: Nathan Gibbs on Flickr

Hovewer, over and over again I observe the following scenario:

Customer: Hey, could we have feature X in our product?

Development Team: Well… it all depends on your priorities.

Customer: Yeah, this X is really important.

Development Team: OK, in our Backlog next things to work on are Y and Z. Should we do X before?

Customer: Ah, no! Y and Z are crucial too. Hm… Maybe we could implement X immediately after Y and Z?

Development Team: Yeah, sounds like a plan. Although we will still have several important things to do after Z for the upcoming release, so we will have to see how X fits.


Development Team: OK, let’s put X to the Backlog and we will see.

And you know what? Quite often this X stays in the Backlog forever.

This is what I call saying “Maybe”, instead of “No”. Backlog is a safe option to close such a conversation, but unfortunatelly later on no one dares to remove anything from there, so lower part of Product Backlog becomes Idea Trash.

Possible solution

Here is what I suggest:

  • Keep very small, focused “Backlog” (better name “This week” or “This release”)
  • Put a hard limit on number stories in it. In other words, limit WIP, where story in the backlog is also considered as “in progress”
  • Anytime you are tempted to break the limit, remove less important stories from the Backlog
  • Most importantly: Have a clear working agreement that removing an item from the Backlog does not mean rejecting to do it at all. You can add such a story later when it becomes important enough.

I am using such an approach on my Personal Kanban board and I would love to give it a try in a project. Actually, this post is triggered by our hassles with managing Backlog in Codebrag and by writing my thoughts down I hope to convince my teammates to give it a try 😉 [update: We have tried it in Codebrag and it works very well]

The idea behind this is making an issue of “There is always more to be done than our capacity” more (frequently) visible. I believe that having a clear backlog helps having clear mind and making better decisions.

The argument against this approach I hear mostly is that something important or innovative might be forgotten if not written down. I disagree. If a user story really “loves” me, it will come back. Otherwise it is not worth my effort.



5 thoughts on “No Backlog Policy”

  1. Hi Pawel,

    Is the “Start with no” strategy working for you? I don’t know any PM/Scrum Master who is able to make this concept work in the real world.

    1. Well, yes it works for me, for example in Codebrag and other projects at SoftwareMill I were involved.

      The thing is that often we say “No” but put the policy is to put an item to Backlog anyway, which builds a pile of stories for which we initially said “No” but they clutter the backlog.

  2. Thank you for this excellent post. I felt the pain of huge backlog many times and totally agree with you.

    What I have seen working out for a couple of teams recently is having a free-text document as a product roadmap. In this document the teams describes their future plans for the product in an abstract way. Internal and external stakeholders get a clear picture where the product is heading, but they don’t drill down to specific features.

    Do you have use similar?

    1. Thank you very much, Nik.

      A high-level text document (as I understand edited collaboratively) sounds like a very interesting alternative for traditional “list of user stories” which we usually use. I have got to give it a try 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s