Impact Mapping on One Page

The Limited Backlog - Addendum

In an earlier post I argued to limit the size of your product backlog. Some days ago, I met a co-worker who told me that some agile experts told him, that product backlogs always have to be limited in size. Superficially, this looks like the very same statement, I made in this former blog post. You might eventually be surprised to read, that I disagreed with the statement, my co-worker made.

Why? Because it is very important to understand why and when limiting the size of your backlog makes sense! The main argument for limiting the size is to avoid the maintenance costs of many backlog items. Especially, if there is a probability, that they will never be implemented at all or the items are deteriorating fastly (what a waste!).

Now comes the pitfall: If limiting the size of your backlog leads to emerging "backlogs" in other places (e.g. at your customer!) you might eventually even increase the overall costs of maintaining the items, if the maintenance costs at the other spots are even higher than they would be in your backlog. This is definitely not what you wanted to achieve in the first place, when you limited your own backlog.

So if you do indeed limit your backlog (which is still extremely valuable), watch out and have a careful look, if the discarded items do indeed vanish, or are only cultivated elsewhere.

The Backlog - Keep it Short!

A problem faced by many Scrum teams is an overcrowded Product Backlog. But the even bigger problem is that many of those teams do not even see, that this is a problem! Why is it not a good idea to have a very large pool of work to do? It might even look like a positive message in the first place.

The problem with overloaded backlogs are manyfold:

• A backlog must be maintained and communicated. The longer the backlog, the more work this is.
• A long backlog often contains items, that will never be implemented - bringing those to the backlog and maintaining them is a waste of time and resources.
• A long backlog has a frustrating and demotivating effect. Nobody wants to feel like Sisyphos all the time.
• A long backlog is nothing more than a long queue. You might read "Flow" by D. Reinertsen and let you convince, that long queues are one of the worst things that can happen to you in product development.
• ...

But what is the solution to this problem?

An obvious and easy solution would be to limit the work pooled in the Product Backlog (i.e. applying a WIP constraint on the Backlog). You can do this either by limiting the number of Stories in the Backlog or by limiting the number of Story Points. Two questions emerge immediately from this approach:

1. What will I do with the work, the customer wants me to do that does not fit into my product backlog?
2. What might be a reasonable upper limit for the amount of work in the Backlog (maximum queue size)?

My first answers would be:

1. If the customer has work to do that is more important than work currently in the backlog - let him replace some items. If the customer asks for less important features tell him to come back later. This approach adresses many of the problems with long backlogs and makes transparent to the customer that he is working with a bottleneck (your Backlog!). You can then work on problems causing this bottleneck.
2. Inspect and Adapt on this number! A good first shot would probably be to limit the backlog to the work that is possibly achievable in three month. This depends largely on your context and how stable requirements or User Stories are.

If this solution seems to be to mild for you and you need more radical solutions this article might be a valueable source for you :-)

Update 1: Some further remarks on this topic.

Priority Race - A Game for Effective Retrospectives

I will introduce a game I invented for facilitating effective and active retrospectives. As every experienced ScrumMaster knows, it is not only important to prioritize (or more correctly: order) your product backlog, but it is also important to prioritize your impediments. This game can help you, making retrospectives more active and fun while obtaining a good order for your impediments.

Material: Non-transparent tape, Scotch tape, flashcards or sticky notes (red and green), flipchart marker, wall or big table

Preparation: Before the retrospective begins, you will have to search for a wall, where you can draw some vertical lanes with your tape. You can alternatively use a large table, which is the second best option. Mark the lanes as follows:

Initial setting: Draw some vertical lanes on a wall (this is the "race track")

It often helps, to put numbers at the top of every column (you can do this easily, using post-its).

How the game works

Step 1: Split your team into several groups of approximately four people. The groups then collect positive and negative feedback on cards (you can alternatively let everybody bring his own feedback, but I like having initial conversations in small groups).

Step 2: Let the groups explain their feedback and put the cards on the wall/table. At the same time, group the feedback cards to clusters of equivalent topics.

Step 3: Put all card clusters to the starting line of your race track, that is position 0, as depicted below.

Put the impediments and things that work fine in the first column (column 0)

Step 4: Now everybody has to execute two moves with green and two moves with red cards. I.e. advance one card two columns to the right or two cards one column with every color. Everybody should try to get her favourite feedback cards as far as possible to the right (but at most two steps). Do this until everybody executed four moves. You can either let the participants do their moves one after another or at the same time (which saves time).

Player 1 advances two green cards one column and a red card two columns

Player 2 moves two green cards one column to the right, and so does he with two red cards

Done: The result will be, that all cards are distributed on the racing track. The distribution is not arbitrary, but reflects the prioritization of the issues in the team.

All Players moved four steps: Prioritization is done.

 
You are now free, to continue with your retrospective, going through the feedback from the right to the left. You can also take a fixed number of green and red cards to focus on in the remainder of your retrospective or take the order as input for your impediment backlog.

You could now focus on the top three cards for further discussion

Hint: You should do some computation before starting the game: Depending on the number of participants you should adapt the number of columns or/and the number of allowed card moves to do for every participant.

You can also use this mechanism for prioritizing any other kind of material (even your backlog) with a larger group of people. I used this game with up to 20 people, prioritizing up to 20 items.

Real world example: Initial setting

Real world example: Result

The great advantage over prioritization with dots or other markers on the cards is, that the result is immediately clear and much more intuitive and visible. No counting - just looking!

Just try it - and if you have any ideas for improvements, different applications, variations, or positive or negative experiences I will be deeply grateful for any comments.