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.

Bild

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.

Bild

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

6 Kommentare

  1. Hi,
    I hope Scrum doesn’t treat ALL variability as impediments! This article gives the impression that variability is generally bad because it makes estimating hard. All examples in your list of causes of variability are negative.

    Generally variability itself is positive, and innate to knowledge work and product development. It is a source of competitive advantage. Some causes of variability are negative however.

    If I had to choose between driving out variability to make estimation easier, or accepting and understanding the nature of the variability in knowledge work, and coming to terms with the relative uselessness of estimation (especially compared to measuring), then I would prefer the latter.

  2. Thanks for your feedback Kurt. I tried to make the blog post as simple as possible. I guess I made it too simple. I revised the blog post to make it more clear. I agree with everything you wrote. Driving out all sources of variability would lead to poorer products and kill innovation completely.

  3. Bernd: Counting PBIs as well as story points come with a large deviation from the average. When people would track hours per PBI they would recognize that the estimation is plain wrong per PBI.
    Counting and story points work in practice due to the law of large numbers: the deviation averages out.
    Therefore counting is less precise than hours on a per PBI level. On a product level with lots of PBIs the precision often is comparable.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s