I recently started reading 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 quiz 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 accuratethan estimates expressed as wider ranges. We believe that wide ranges make us appear ignorant or incompetent. 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 believe 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 life cycle. 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 uncertainties 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 is 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 Pointsproperly, 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 used both and can honestly say I prefer using points.  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. It’s also important to make sure that your stories are Small enough to consume without breaking them down further.

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.

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

Related Articles:

• What’s my Team Velocity? (agile101.net)
• Does Agile Programme Management Exist (agile101.net)
• Agile Programme Management and Epic Boards (agile101.net)
• Lean, Scrum, Scrum of Scrums and Epic Boards (agile101.net)
• Introducing the Agile Epic Board (agile101.net)