Agile 101

Project Management, Digital Publishing and Agile Software Development

Posts Tagged ‘Story points’

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.

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

Advertisements

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

Software Estimation – the more precise you are, the less accurate you will be!

Posted by Tara Hamilton-Whitaker on July 17, 2009

estimationI recently started reading “Software Estimation – Demystifying the Black Art”, By: Steve McConnell off the back of a recommendation by a fellow colleague – lots of useful info. In any case, I thought I’d share a few great learnings that helped me to get my head around the human being’s ingrained desire to get things ‘right’.

We often confuse ‘accurate’ (mean difference) with ‘precise (variance)’. It would be accurate to say that I was less than six foot tall, it would be precise to say that I was 5.6789048392…ft. (I made that part up…I don’t actually know my precise height, but my sister tells me it’s less than I think it is).

We can be and often are more accurate, as we become less precise. Steve sets the scene by asking readers to take a quiz – fun. I like interactive books!

He asks 10 questions e.g. Surface Temperature of the sun, Latitude of Shanghai, Total volume of the Great Lakes. The brief is to define an upper and lower bound that has 90% chance of containing the correct answer. To pass the quizz the reader would need to get 9/10 correct.

Easy!! Just set the boundary values REALLY wide, right?? Hmm… so… Out of a study of 600 people, the average number of correct answers was only 2.8. Only 2% of quiz takers scored more than 8 answers correctly.

Steve goes on to write:

“We are conditioned to believe that estimates expressed as narrow ranges are more accurate than estimates expressed as wider ranges. We believe that wide ranges make us appear ignorant or incompetant. The opposite is usually the case.  (Of course, narrow ranges are desirable in the cases when the underlying data supports them.)…….After discussing this issue with hundreds of developers and managers, I’ve concluded that much of the pressure to provide narrow ranges is self-induced.  Some of the pressure comes from people’s sense of professional pride.  They belive that narrow ranges are a sign of a better estimate, even though that isn’t the case.”

Steve then goes on to talk about the “Cone of Uncertainty“, which describes the change in uncertainty during a project lifecycle. It makes sense that estimates will be the most innacurate before you actually get stuck in. How can you know how long something is going to take if you’ve never done it before? (It sounds so obvious when you say it like that).

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 narrows as you eliminate uncertainties.

In software development, you will more often than not be faced with building something that you’ve never built before. You may be working with people you’ve never worked with before. You may be waiting for a design from a Software Architect that has never designed something like this before (even if you do have experience in this area). There are so many uncertaintees including Business As Usual disruptions, bugs that are there hiding, waiting to catch you out.  Although it is possible to minimise the impact of sprint disruptions, it’s very difficult to know what they’ll be in advance – otherwise you’d be able to estimate them.

The wonderful thing about Story Points is they 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.

Story Points are also abstract so people feel less threatened by them – if you think something’s going to take you 4 hours and someone else says it should take 2, you introduce an unhealthy sense of competition into the mix.  This can be dangerous, especially since people already have this ingrained tendancy to under-estimate for fear of looking less capable. Statistics suggest that both estimates are inaccurate anyway, so what’s the point in getting personal?  On the flip side, it’s harder to feel bad for saying you think something’s ‘a five’ vs. someone else’s ‘three’.

Also, if a team is historically risk averse and they commit to 5 days work, you can’t turn around to them and urge them to aim for 7 (!).  On the flip side, if a team commits to 2.5 days work but spends the entire time working and delivers on time – are they under performing?  Maybe, but probably not.

Story Points also work well with the stakeholders (once they get their heads around them). Gone are the days where stakeholders add in a 1 hour task because Joe Blogs only has 34 hours of work planned in. We no longer have to explain that a team has a tendancy to under-estimate so we’ll only be planning in 20 hours of work this week – yes, that did happen once. Story Points make things easier.

Since we started using Story Points properly, every one of our teams has increased their velocity over time.  Fact. The more established teams rarely deliver less than they say they would. Fact. If anything, they’ve become so much more aware of how much work they can deliver as a team that they’re able to easily adjust their velocity to accomodate holidays, and new starters etc.

Now, with all of this said, there is still a lot of debate surrounding whether you should estimate sprints in hours or Story Points.  Mike Cohn is against it, Jeff Sutherland is for it.  I’ve done both and can honestly say that I prefer points in all cases – they’re just so much easier!  The only caveat is that with points, you burn down upon task completion, whereas with hours you burn down at the end of the day regardless of whether you’ve finished the task or not.

The problem with burning down upon completion is that it could take a little while before you realise you’re behind schedule – this is why it’s important to keep your stories small/sizeable. You can, of course mitigate this by making sure that each team member answers the 3 Daily Scrum Questions on a daily basis (What did you do yesterday, What will you do today, Any impediments?).

In any case, I can definitely say that by reducing precison we have become more accurate. It took me a while to get my head around it, but it’s absolutely true – if you’re still using hours, have a go at calculating your velocity with Story Points – you’ll not regret it.

Related Articles:

Reblog this post [with Zemanta]

Posted in Agile Estimation, Project Management | Tagged: , , , | Leave a Comment »