Estimating - Do you know how to size Product Backlog Items (PBIs) effectively?

Last updated by Tiago Araújo [SSW] over 1 year ago.See history

A team knows how many PBIs they can commit to by measuring their velocity. The Team estimates the highest priority PBIs in the Product Backlog in Story Points. It is very important for teams to estimate tasks effectively. There are several methods for estimating:

  • Shirt Sizes
  • Fibonacci Extended (1-100)
  • Fibonacci Original (1-21)
  • Doubling
  • Thrown

Let's go through them:

Shirt Sizes

This method is popular with Microsoft teams, but it has the problem of not easily mapping to the common 7 numbers when you enter it into a Task tracking Bug database.

1 = XS
2 = S
4 = M
8 = L
16 = XL
32 = XXL
64 = XXXL

Note: In some teams which only use Small, Medium and Large the following numbering is applyed respectively 2, 4 and 8.

size stories bad example
Figure: Bad example - Estimation using T-Shirt sizes

Fibonacci Extended (1-100)

Planning Poker is a very effective Product Backlog estimation technique and the most common method is using Fibonacci numbers (1,2,3,5,8,13, etc.). This was made popular by Mike Cohn.

size stories ok example
Figure: OK example - Estimation using Planning Poker with large numbers

Fibonacci (1-21)

Mike Cohn introduced changes to the original 7 cards, by changing the 21 to 20 and adding 40 and 100 to indicate very large user stories called Epics.

Ken Schwaber (the father of Scrum) says in his Scrum Certification course, that he is not a fan of the extra cards and says he prefers teams keep to the original 7 cards.

size stories good example
Figure: OK example - Estimation using Planning Poker with only small numbers

Estimating using doubling numbers makes relative sizing simple. An 8 point PBI should be about twice the size as a 4-point PBI. This method also simplifies PBI swapping where a PBI is replaced with PBIs totaling the same number of points.

It has one other advantage over the Fibonacci sequence, it is easier for non-techies because the numbers aren't whacky and the name isn't bizarre.

Estimate
1
2
4
8
16
32
64

Figure: Good example - Doubling simplifies relative sizing

Thrown

Another method of estimating is the "Thrown method" as described Martin Fowler.

This is particularly useful if you don't have Planning Poker cards. Instead of Fibonacci numbers, estimates are from 1 to 5. It's nice and simple, and you only need the fingers on your hand.

The action is done in the same method as the game 'Rock, Paper, Scissors'. The options the developer can estimate is 1,2,3,4,5.

fist method
Figure: PBI estimates using the "Thrown method"

Other Tips

#1 Don't Shout Out It will just influence other people's votes.

#2 Guidelines for Estimating PBIs (aka Anchoring) Every team is different, but you can use the following guidelines for sizing PBIs.

Estimate Value Example PBI
1 A less than 2 hours message box change
2 -
4 A timeboxed task for 1 day x 1 developer
8 A timeboxed task of 1 day x 2 developers
16 -
32 -
64 More than a month with a couple of developers (Don't include these in a Sprint because they are too risky. See #4 below)

Figure: Good example - Example PBI estimates

#3 Using a Chat Program If you are working on a project with a remote team, use Microsoft Teams chat to size PBIs using Planning Poker. Everyone should give their points for PBIs at the same time to avoid influencing each other.

#4 Big PBIs Smell PBIs of greater than 2 days are a smell and PBIs greater than 4 days are a stench. If PBIs are estimated at more than 4 days of work, consider splitting them into smaller pieces to keep them under 2-4 days. See Do You Break Large Tasks into Smaller Tasks?

#5 Use Spikes If you do find a very large PBI, consider using a Spike (aka. an investigation task) to help work out how much work will be involved.

We open source. Powered by GitHub