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.

Making the Case for Story Points

Or: Why Story Points Outperform Man-Days easily

I introduced Scrum to a number of teams now. There was always big discussion whether estimation in Story Points is of any use. I think estimating in Story Points is one of the really great inventions of the Scrum framework and I want to draw out the reasons for this believe in this post.

Estimating in Story Points has great advantages in multiple aspects:

Team Advantages

• Story Points are a team metric. They are always estimated by the whole team. In my experience those estimates clearly outperform man-day estimates, since they depend not so much on who actually carries out the estimated task. Thus Story Point estimates are more reliable.
• Since everybody in the team participated in the estimation most people feel more accountable for the work behind the Story. This is often not the case with man-day estimates which are in many cases given by experts and carried out by someone else.
• Since the whole team estimates, much more information is shared among team members. This supports reducing islands of knowledge.
• In emerging discussions during estimation open questions and risks are discovered very early.

Abstract Number Advantages

• There is no immediate connection between Story Points and real working hours. This makes estimation often much easier and removes useless points from the discussion agenda in estimation meetings.
• Estimating in Story Points makes you almost immediately think a little more abstract during the estimation. You often do not loose yourself in the details of the implementation which makes estimation faster but still accurate enough.
• Story Points are usually estimated in fixed and fastly growing steps (e.g. the Fibonacci Numbers). Therefore the amount of uncertainty and risk is simply expressed in the resulting number. The bigger the number - the higher risk and uncertainty. This is clearly expressed by not having numbers like 427 available (which would suggest high accuracy for outside observers).
• You can estimate earlier in Story Points than in man-days. The reason is that you can much earlier say how big a task is relative to other tasks, than to determine exactly how many days you would need to implement it. Relative estimation seems to be easier to accomplish for human beings than absolute estimations.
• Estimations in Story Points are often more honest than estimates in man-days. The reason is, that you do not have the feeling to "promise" to be done in X days.
• Since the Story Point number is abstract you do not have the temptation to build in buffers. Thus you have much better control about the real state of work.

Efficiency Advantages

• Estimation in Story Points is often much faster than classical estimation in man-days. Many of the reasons for this point are still mentioned above. Additionally, there are methods to get those estimates really fast (e.g. Planning Poker or Magic Estimation).
• By estimating in Story Points you avoid unnecessary discussion and justification for the time needed ("Why can't you do this in three days? Five really seems a little to much...").
• You additionally avoid useless discussions about teams performance ("you are three guys working five days a week - why did you only finish work estimated for six man-days last week?"). To be clear: discussions about teams performance (positiv or negative) are legal and often good hints for impediments, but not in the indicated tone. Thus Story Points can switch your attention from justifying to solving problems.

Self-Improving Mechanism

• In my experience you get an excellent predictability for your projects progress with Story Points in early project stages. This is because Story Points contain a self correcting mechanism. Slow or fast progress will show up early in the project.
• If you made some errors during your estimations the errors are very likely to be averaged out. Thus you do not have to care so much about the correctness of your estimates, which saves you good amounts of time.
• The estimates in Story Points are self adapting. If a team changes, the mechanism adjusts itself immediatly. If the teams performance increases or decreases you do not have to re-estimate. All estimations stay valid and you can still easily predict progress.

I do not love to say this, but there are two disadvantages at hand with Story Points from my point of view:

Shortcommings

• Firstly, they are hard to explain. Almost everybody is familiar with some estimation in man-days. The concept of relative and abstract estimates are difficult in the first place. But this vanishes after only a few weeks.
• The second point is that in our times and organisations you often have to do some recalculation from Story Points to man-days for financial reasons. This is easy, but is work that generates only limited value.

If you have any other arguments on estimations in Story Points - feel free to comment on this post.

In essence, the central goal of estimations is to get the necessary metrics and information to make progress transparent. This is obviously possible with both, man-days and Story Points. But considering the huge amount of advantages of Story Points this - at least to me - seems to be the better and more efficient way to achieve this.

But after all - it's an estimation technique and the only thing you can be certain about is that it's to some degree uncertain.