Sizing the elephant with relative estimation and Story Points

We need to ensure effective tracking of progress on completed work. We also need to predict how much future work we have to a release. We could make all the work items equal (rightsizing) and use a counting (noestimates) approach. But this is unlikely to be sufficient.

We need to know how big each item is relative to the others.  Then we can earn more for completing a big item than a small one. And we can anticipate more remaining work if we have big items remaining.

But what does sizing mean? In a classical project, we take a reductionist approach. We break the work down and assume we can accurately estimate the time a task will take in working hours.  We then judge how many hours a team member has available in a week.  And this tells us how long it will take to complete each task.  In a complex Agile environment this approach is not realistic.

Relative estimation

Instead, we use a relative estimation approach.  We are tracking progress by the fraction of work completed.  Therefore the size of individual items on any absolute scale is not critical.  What is important is that a piece of work which is twice as big has twice the score.  This approach is called relative estimation.  Relative estimation involves focussing on the relative sizes of work items relative to each other.  Relative estimation has some distinct advantages as an approach but it also has some challenges when we roll out in the organization.  As always, establishing language and communication are key here.

It has often been demonstrated that people are much better at sizing items relative to each other.  Assessing relative size is easier than assessing actual measurements.  When performing relative estimation, we are not looking at the actual hours an activity will take.  We are assessing the backlog item against past similar backlog items.  This can significantly simplify the process of estimation. 

People are surprisingly good at relative estimation.  Look at these three lines. The second line is 60% the length of the first.  The third line is 80% the length of the first.  These proportions are fairly easy to judge by eye.  How long are they in millimetres on the screen?  That is significantly harder to estimate.  The same difference between relative and absolute estimation is true in development.

Estimation approaches

There are three basic approaches to estimation units.  These are different units.  However, correctly managed, each of them can be interpreted as relative estimation.

Rightsizing

All work in the next timebox is broken down into similar sized work items.  Then all items have a roughly equal relative estimation value. 

This simplifies the approach but can be treated the same as other relative estimation. However, as I noted earlier, rightsizing all work up to a release point can lead to an “up front planning” mindset.

Story Points

Each team sets its own baseline scoring based on the size of past work.  If they size the top line in the drawing as 10 points, the second might be 6 and the third 8.  However, these numbers have no absolute meaning.  They are not centimetres or pixels. 

It does not mean that a particular task takes a particular time.  Different teams may use different baseline values for the same work item.  The top line above might be 10 points to one team and 20 to another team.  However, each team keeps the same relative values.  The second line is always 60% of the first.

Effort Based

Rather than an arbitrary scoring system, the estimates remain based on effort.  For the initial line, instead of assigning an arbitrary 10 points, we might say that when we did an activity of that size before, it took 2 weeks of effort. 

This means that the second item (60% of the size) would be six days of effort, and the third item eight days of effort.  Although we are introducing effort, this is still relative estimation.  We are not producing the estimate by decomposing the work into small tasks and adding these up.

Good practices

As an Agile leader you need to work with the teams to build skills in relative estimation. Avoid referring to “working hours” or similar reductionist approaches.

Decide with a team if they will use story points, effort based or rightsized estimation. Keep consistent with that team.

Focus relative estimation on rapid, high-level assessment to make risk-based decisions, not on detailed bottom-up breakdown.