Software Development Insights

Why User Story Points Help Agile Effort Estimation

Royd Brayshay
30th May 2012

Home Insights Why User Story Points Help Agile Effort Estimation

Story Points seem to enjoy a perpetually difficult place in the lives of many agile teams. They are the source of much confusion and teams often choose not to adopt them.

The traditional practice of quantifying work in days or hours seems so obviously straightforward. Redefining time must only bring confusion – surly? Others have done a good job of explaining the direct relationship between user story points and time. Here we’re interested in why use them at all.

To understand the concept better try thinking about the overall plan and not individual user story cards. Aggregating user story points reveals the size of the mountain ahead. Using data collected from the past reveals how fast the mountain will be climbed. The beauty of Story Points is not the points themselves but their use and calibration against past progress data. Not knowing a team’s past work rate, often called velocity or flow, is a common missing link.

Using the mountaineering metaphor there are many things that affect a team’s speed of assent. Bad weather, altitude sickness,  or getting lost will all influence progress. Looking back at each days altitude gain will give an increasingly accurate prediction of reaching the summit. Mountaineering, like software development, unfolds unpredictably. The key point is that the plan can be recalibrated with each day that passes. As more performance (climbing) data accumulates the clearer the outcome becomes.

If a software team uses time , much of the context is missing. If they estimates a job at ten days, Is that ten perfect days? Is that ten days at sixty percent efficiency? Do they need the best talent in the team assigned? What if the team doubles in size? Re-estimation can help when things change or the wrong assumptions made; but estimation is expensive. What if a hundred user story cards exist? A day or more could be lost and re-estimation needed multiple times.

Image yourself on holiday in an unfamiliar country. You want to visit a notable tourist attraction and, to make a plan, you ask a local how long it will take to get there. They respond with “two hours”; but is that by bus, on foot, or in a rental car? It could be five or fifty kilometres away. Alternatively, if the answer was “eight kilometres” you can mentally calibrate based on the available transport and, importantly,  your past knowledge of its velocity.  If your transport changes you intuitively recalibrate. Using none time based sizing is unambiguous and more versatile.

Sizing with a non time based unit and calibrating the volume of work ahead against the rate of work completed, provides a constantly re-adjusting prediction of the future.

Share Article

Insights.

Taking a look at Dagger
Taking a look at Dagger

Solomon Hykes is probably most famous for being the founder and former CTO of Docker. Docker revolutionised the way we package, run and distribute server applications, so when Hykes starts a new venture, it's worth checking out.

Discover More
Running Terraform in a Lambda Function
Running Terraform in a Lambda Function

I recently set up a Terraform project which I wanted to run on a regular schedule. There are a number of ways to achieve this, but I decided to package the project as a Lambda function and schedule it with… 

Discover More
Setting up AWS SSO with Google Workspace
Setting up AWS SSO with Google Workspace

I recently configured Single Sign On (SSO) from our Google accounts to AWS. AWS SSO is the recommended way to configure SSO across multiple AWS accounts, yet Google is not a supported identity provider. However, this simply meant that there… 

Discover More