The items in the Product Backlog each have an estimate of the amount of work required in order to complete them. This allows the Backlog to be effectively refined and managed.
- Allow the Product Owner to properly prioritise the Product Backlog – they can only do this when they have a proper idea of the relative cost of items.
- It enables high level forecasts to be made. The proposed story points can be plotted in the burn down chart.
- The Product Owner can make better decisions around scope and schedule – i.e. how important is that ‘must have’ feature, now that it’s been estimated to have a large effort required to complete it.
When to Estimate
Our team performs estimation of Product Backlog Items during the Backlog Refinement meeting.
The earlier you estimate, the earlier the Product Owner has information that can be used to prioritise the Product Backlog. You’re not held to the estimate – if more information comes to light, or the item changes, then the estimation can also change. It may also be useful to confirm that estimations are still accurate when items are pulled into the Sprint Backlog. Even though the time between the Backlog Refinement Meeting and Sprint Planning may be short, there is still the potential for Product Backlog Items to change or be clarified.
Why we estimate in points
Story Points provide relative values for the level of effort needed to complete a Product Backlog Item. They take into account:
Effort – the amount of work to do.
Risk and Uncertainty – how much or how little we know about the item.
Complexity – how complex is the logic that we have to work out or the code we have to write.
The final estimate will be a combination of these elements.
Have you ever given an estimate in hours and then overrun, even if only slightly? I’ll bet the next time you gave an estimate, you added on some extra time as ‘wiggle room’.
The issue with hours is that they’re absolute and provide a false sense of certainty.
With story points, the estimates are relative, so we don’t say how long a particular item will take, just that it requires, for example, double the effort of another item.
It doesn’t matter what values we use, as long as they are relative. So an item with 2 story points is double the effort of an item with 1 story point.
Deciding on a scale – Fibonacci
Although you could just use 1,2,3, etc, this doesn’t really reflect the increasing effort required as the numbers are close to each other. Instead, we can use the Fibonacci numbers, where each number is the sum of the previous two e.g.
1, 2, 3, 5, 8, 13, 21…
Don’t pick too many numbers for your scale, but you might also want to include a large number such as 987 or infinity, for assigning to items that are too large to estimate.
How to estimate
Before you can start estimating all your PBIs, you need to establish a base story. This is the most basic item that you can find on the Product Backlog and one that everyone understands well. This item is assigned a story point value of 1.
You can also assign points to a number of other items, in order to give a range of base stories from the simplest to the most complex – these stories can be real or can be created specially for this task.
Below I’ll detail some techniques that you can use to estimate.
Probably the most popular technique for estimating is Planning Poker.
First, decide on a ranking scale for items – as previously mentioned, the Fibonacci sequence is popular (1,2,3,5,8, etc).
In a group, every person has card for each of the ratings. You might also have cards with images, such as a cup of coffee – to represent when someone wants to take a break. Or something to denote when the discussion has gone off topic – I’ve seen a cartoon rat used, as in ‘going down a rat hole’.
The item to be ranked is read out to the group and each member selects a card based on their perceived estimation of the work involved. They must keep their card hidden until everyone has chosen.
Once every member of the group has selected a card, they are all revealed simultaneously.
If the selected estimates are all similar, then the group is in agreement. If there are outliers, then the differences must be discussed in the hope of aligning everyone’s views on the required estimate.
The same item is then estimated again by repeating the steps above in the hope of achieving consensus. If consensus still can’t be reached it may be that the item needs refining into smaller items or that an average (median) score is used.
Alternatively the group may need to decide not on the ‘perfect’ estimation, but one they can support.
As an alternative to using numbers, some teams use t-shirt sizes (S, M , L , XL) to estimate. This can provide an easier way to get started, especially if teams are afraid to commit to a number as they are even more abstract. However they can cause some issues:
- They will need to be converted to numbers at some point if you want to plot burn down charts.
- People may have different views of the relative effort required for a particular size. So, is a Large item twice as big, or ten times as big, as a Medium task?
Each member takes a card representing a Product Backlog Item from the pile and adds it to the table. They position in it relation to how large they estimate the item to be – largest items go at one end of the table and smallest at the other end. The next person takes a card and places it on the table, in relation to all other cards. Or they can choose to challenge the position of an existing card. If they think it requires relatively more effort, it goes higher up the board, above the lower effort items.
Once all the cards are placed and the team are in agreement, the items are assigned an estimate using the Fibonacci scale. Starting at the smallest item, assign the card an estimate of 1. Repeat this for the next item up the table. Move up the table until you reach items that you would estimate as 2, then 3 and so on.
Once you’ve estimated the Product Backlog Items, the Product Owner can use those estimates to help them order the Product Backlog.
Over time, the teams’ estimates will become more accurate and they will have a better idea of what can be fit into a Sprint. This process can be sped up by utilising the Sprint Retrospective. The team looks at the estimates they gave for items on the previous Sprint and compares them to the actual amount of effort required. Using this knowledge, they can Adapt their estimation for the next Sprint.