The Cone of Uncertainty is a Project Management term used to describe the level of uncertainty existing at different stages of a project.

In short, we become more certain of our estimates as we learn more about what we’re estimating.

In Agile Project Management environments, we accept that software projects are ridden with uncertainty – it comes with the territory. This uncertainty decreases as decisions are made around scope and approach – the more we understand, the more certain we can be about our estimates.

To mitigate the risk of incorrect effort estimations we reduce the precision of our estimates according to how much we know about what we’re estimating. This in turn helps us to be more accurate.

(See: Software Estimation: The more precise you are, the less accurate you will be).

Agile Requirements in order of Uncertainty

1. Agile Theme
2. Agile Epic
3. Agile User Story
4. Agile Task

(See: The Difference Between Agile Themes, Epics and User Stories)

Agile Estimation Techniques in order of Precision

1. Hours
2. Story Points
3. T-shirt Sizing

Estimating in Hours vs. Fibonacci

As described in my post Software Estimation: The more precise you are, the less accurate you will be, studies suggest that estimates taking place during the Product Definition Phase exist somewhere between being 300% less and 0.75% longer than it actually took them to build the software i.e. out by a factor of x16. The cone of uncertainty narrows as you eliminate uncertainties.

In Agile environments, we use two main estimation metrics – Fibonacci and Hours.

Estimation using hours is pretty self-explanatory, however it’s worth mentioning that Agile Teams only estimate Tasks in hours.  By Tasks, I mean ‘parts of a User Story’…something very small that should take a couple of hours or so – definitely no longer than a single day to complete.

Why?

Because larger pieces of work are generally more complex and should/could probably be broken down into smaller component parts AKA there may still be a number of outstanding decisions that could affect the level of effort required to deliver the task.

The larger the task, the lower the chances that you’ll be able to estimate the exact number of minutes/hours associated with delivering it e.g. Phone interruptions, toilet breaks, delayed meetings.

In other words estimate SMALL things in hours.

Estimating in Fibonacci is the second Agile estimation metric - we call this Story Point Estimation.  We use Story Points to estimate larger pieces of work i.e.  User Stories and Epics.

They work as follows:

0,1,2,3,5,8,13,21,34,55,89

In other words, a ’5′ is 5x more effort than a ’1′ and an ’8′ is 8x more effort than a ’1′.

Story Points can measure things we can’t measure in hours – e.g. complexity – do you include a task for every discussion you don’t yet know you need to have, every time you take 10 minutes out to Google an answer? It is however relatively easy (when you get started) to compare the size of one task/cluster of tasks with another task/cluster of tasks.  Estimating in Story Points allows you to take into consideration all sorts of intangible ‘things’ that you sense but can’t quite put your finger on.

(See: Software Estimation: The more precise you are, the less accurate you will be)

Estimation Using T-Shirt Sizes

T-shirt Sizing is an Agile Estimation method – it’s used to estimate larger requirements i.e. Epics, but maybe the odd User Story also.

In short, you attribute a number of story points to a t-shirt size e.g. an XXL might equal ’55 points’ as shown in the diagram below. T-shirt sizes are great for Product Owners and/or non-technical people as they’re totally abstract and non-threatening (that’s not meant to sound patronising…you know what I mean!). They’re easy to understand.

When estimating in T-shirt sizes, it’s still important to set your scale – agree in advance what constitutes a ‘Small’, ‘Large’ and ‘XX Large’.

T-shirt sizing will normally take place at the Requirements Workshop – this helps the Product Owner and Product Manager get a sense of scale, which will in turn help with the prioritisation process.

As always, the Scrum Team are the people that assign t-shirt sizes to Epics.  The Product Owner and/or Product Manager are not allowed to participate in the estimation process – they can offer insight and guidance but the estimations belong to the Scrum Team.

Estimation Using Story Points

Once the Epics have been estimated and prioritised for delivery, they will be broken down into User Stories by the Product Manager and Product Owner.

The component User Stories will then be introduced at a subsequent requirements workshop and estimated in Story Points at Poker Planning.

(See: Scrum Sprint Planning Meetings: Who, What, When, Where, Why)

Read more about Agile Estimation

Subscribe to the to be notified when I upload new Articles, Videos, Templates and Tips!