Agile 101

Project Management, Digital Publishing and Agile Software Development

Archive for the ‘Agile Estimation’ Category

Agile Estimation and the Cone of Uncertainty

Posted by Tara Hamilton-Whitaker on August 18, 2009

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.


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:


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 Agile101 RSS to be notified when I upload new Articles, Videos, Templates and Tips!


Posted in Agile Estimation, Themes, Stories, Epics | Tagged: , , , , , , | 3 Comments »

Value Points – Estimating the relative value of a User Story

Posted by Tara Hamilton-Whitaker on July 22, 2009

priorityValue Points can be used to measure the relative value of User Stories using a Fibonnaci Sequence. Although not appropriate or particularly necessary in all cases, Value Points can help you to prioritise a product backlog and convey the relative importance of User Stories to a Software Development Team. This approach becomes increasingly useful as teams scale to cover multiple projects combined with Business As Usual activities.

If you are a Product Owner or a Programme Manager, you will be all to familiar with Return on Investment (“ROI”) models, Net Present Value(“NPV”) and Internal Rate of Return(“IRR“).

In short:

  • ROI measures how much money you will make off the back of an investment.
  • NPV measures the desirability of an investment compared to the minimum expected return over a pre-defined number of years.
  • Internal Rate of Return measures the percentage return of an investment after tax.

The traditional ROI model approach is useful when applied at a project level, particularly when attempting to measure viability and/or secure funding, however it is time consuming, requires business analysis skills and is wrapped up in a whole host of assumptions.

In Agile Software Development, we break projects down to Themes, User Stories and Tasks. We then define a minimum feature set (Minimum Marketable Feature(s)) and attempt to schedule development in a way that maximises ROI early on.

So, what happens when you need to measure the value of a User Story?  Do you produce an ROI model? What if there’s no direct financial return associated with the story?  The reality is that this would be an unrealistic expectation due to 1) the time/effort involved and 2) the level of  granularity that would be required.

So, what to do?

I started using Value Points in hopes to simplify the process of measuring relative value. This scale uses the standard Fibonnaci Sequence: 1,2,3,5,8,13,21,34,55,89 as a metric.

In the same way that Story Points can not be converted to Hours, Value Points can not be converted to Financial Return.


Because when we measure value, particularly across Business As Usual, there are so many reasons for doing something – not all of them will offer an immediate financial return:

  • Strategic – if we don’t make this investment, we will no longer be able to maintain our market share
  • Compliance – if we don’t make this investment, we could be in breach of the law(s)
  • Revenue Generation– if we don’t make this investement, we’ll miss out on a chance of making X money
  • Risk Management – if we don’t make this investment X could happen to us e.g. stakeholder dissatisfaction etc.
  • Cost Avoidance– if we dont make this investment, we could realise additional costs in the future
  • etc…

Value Points can offer a useful tool to help with the prioritisation process e.g. you can plot effort against value to maximise delivery of those stories delivering the highest amount of value for each unit of effort.

Value Points can also empower the development team to identify the most appropriate solution for a particular card – e.g. the value’s low, so I’ll not spend as much time on it as one of the higher value cards.

I’ve created a Product Backlog Template that provides some insight into the health of your product backlog – the idea is to pack it with as many low-effort/high-value stories as possible.

This template uses a simple formula to help you prioritise your stories:

Value Points – Story Points = Priority Points

It also allows you to do the following:

  • Assign stories to sprints (release plan)
  • Calculate the number of releases required to deliver your backlog based on your velocity
  • Calculates how many sprints you can afford to deliver based on your project budget
  • Plots your user stories on a chart based on Effort vs. Value

Feel free to download the template below – let me know your thoughts.

Product Backlog Template with Priority Overview.xls

Product Backlog Template with Priority Overview.xls

Related Articles:
Reblog this post [with Zemanta]

Posted in Agile Estimation | Tagged: , , , | 3 Comments »

Agile Balanced Scorecard – Measuring the effectiveness of an Agile Software Development Team

Posted by Tara Hamilton-Whitaker on July 18, 2009

agile-balanced-scorecardPeople often confuse Velocity with effectiveness .e.g. ‘my team are delivering many Story Points therefore they are amazing.’

Velocity does by definition assume a degree of quality output by any Agile Software Development Team, by the virtue of the fact that you should only count accepted Story Points towards your velocity.

With that said, there are many other factors that need to be considered when assessing the overall effectiveness of the team.

Traditional performance management practices such as the Balanced Scorecard use Key Performance Indicators (“KPIs”) to measure the effectiveness of a team.

We can apply this concept to an Agile Development Team by considering performance in the following areas – an Agile Balanced Scorecard:

  1. Reliability – are the team delivering what they say they will? Read more about Reliability
  2. Quality – live defects, beta defects, stakeholder satisfaction  Read more about Quality
  3. Value – are we delivering the highest value User Stories? How productive/profitable are we? Read more about Value
  4. Velocity Read more about Velocity
I have uploaded a few templates that you can download to help you track some of these Key Performance Indicators.
To download these templates visit:
Reblog this post [with Zemanta]

Posted in Agile Estimation, Programme Management, Project Management | Tagged: , , , | 2 Comments »