Shades of Scrum: Estimation of the Product Backlog

The common saying is that in Scrum the development team estimates the Product Backlog in Story Points. This is a good start for a lot of teams since it is a suitable match between business needs and the capability of the team.

But: There are a lot of other options for estimation in Scrum.

Why estimating the Product Backlog?

The first important question is why you want to estimate the Product Backlog. Typically the Product Owner, the management or the customers want to have a release plan. To create a decent release plan the Product Owner needs a good enough estimation of the features that will make the release. (If nobody needs a release plan you may not need to estimate the Product Backlog at all).

The Product Backlog often contains items for following releases. The Product Owner should question the need for estimating these. Often he needs to create the plan for the current release but not plans for all following releases. Therefore the items with low priorities often don’t need to be estimated at all.

How to estimate the Product Backlog

For the items that need to be estimated there are alternatives to Story Points. The team could  estimate in person days, of course. Or they could use T-shirt sizes (S, M, L, XL) or even simpler they could just count the items in the Product Backlog. But counting isn’t estimating, is it?

When you just count items you have an underlying assumption: the variation in size of these items is small enough so that counting will produce a good-enough result. So you estimate that the items are more or less of the same size. You could say that you estimate all items to be one story point.

When to use which estimation technique

When are Story Points appropriate and when is counting sufficient? The so called ”sources of variabilities“ (a concept from Lean Thinking) have a big impact on the decision. Sources of variability make estimations fuzzy or instable. Typical sources of variability in software development are:

• Missing contributions of other departments or companies.
• Missing skills within the development team.
• Wrong or incomplete understanding of what has to be done.
• Exchange of team members.
• Modifications of the Product Backlog (new features are added).
• Illniss of team members.
• Urgent incidents.
• …

The sources of variability interfere with the estimations. It is for example worthless to invest a lot of time in a very precise estimation if the team members are exchanged every week. These exchanges would make the performance of the team totally unpredictable. In that case the precision of the estimation doesn’t matter.

Here is a rule of thumb: The more sources of variability the less precision.

You should do imprecise estimations when you have a lot of sources of variability. Don’t invest your time to refine these estimations (red area in the figure). Invest your time in eliminating sources of variability (moving to right in the figure). It is the bigger leverage. But be aware of the fact that not all sources of variability are bad. Changes to the scope is intended in Scrum – it is the root cause for the Sprint Review. Removing all sources of variability would kill innovation. Therefore focus on the unwanted sources of variability.

After you eliminated the biggest unwanted sources of variability you could make your estimations more precise.

The following figure relates typical estimation instruments to the estimation precision.

P.S.: Scrum is aware of unwanted „sources of variability“. It just uses another name: impediments.