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.

Author: Royd Brayshay

I work with software development teams needing greater business effectiveness. I give lean and agile leadership advice plus coaching and training in Scrum, Kanban and XP practices. Dramatic improvements in productivity and predictability can be found in most teams. I also write code, design products and perform technical leadership.