What’s the Story Point anyway?

I had a great chat with a developer recently about story points and whether they have any value. We spoke about how they’ve been used at his companies, past and present, and how we use them at Nona.

I realised in that conversation that there may be some useful nuggets I can share from our many years of trying to apply agile effectively and how we get value from using Story Points.

What are story points?

Surprisingly (or maybe not) there isn’t an agreed upon universal definition of the story point and giving that phrase a ‘google’ will turn up a variety of results which differ in important ways.

I like the story point definition here by Derek Davidson:

“A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide relative estimates of effort for completing requirements”

The key part of that is “a relative unit of measure”.

That’s essentially what it comes down to. Ignore everything else and focus on the fact that we’re trying to measure something and we’ve elected to do so relatively.

We’ll get into why below.

What do we need to measure and why?

Simply put, stakeholders at the least, and likely ourselves as well, are interested in how long particular pieces of work and entire projects full of work will take to complete.

However inconvenient this truth may be, one can understand how that is a useful piece of information to have regarding a project that needs to be delivered at some point.

Problem 1:

We can be as agile as we want to but someone, somewhere needs to have at least a good approximation of when this will be completed and some hope that the process used to arrive at this estimate is reasonably accurate and fit for purpose.

Why Story Points? Just estimate time in days?

Problem 2:

Great question… why do we use a relative measure? Surely if the objective is to have some kind of idea how long something will take, then the best measure is just “how long will this take in hours/days/weeks”?

We humans, however much we protest this fact, are terrible at estimating how long things will take to do.

Problem 3:

Particularly difficult things that we haven’t done before. Which is usually what software development involves.

Estimation takes long. It’s an arduous process, it is very time consuming, it can be highly stressful and at the end of the day doomed to be wrong anyway?

It feels like there may be a better way to spend this time.

For example:

Situations change. Teams change. Environments change. Coding styles change. These changes affect how long it will take to complete a task in various scenarios rendering previously mildly inaccurate estimates, wildly inaccurate.

So how does measuring relatively help?

The big idea here is that while humans are terrible at estimation, we’re not too bad at relative estimation. Given two tasks or objects, we’re pretty good at comparing them to one another.

“Will it take longer to add the login form or the signup form? How much longer? Roughly twice as long? Or only half as long?”

“Will it take longer to build the search feature or the list posts feature?”

Personally, I’d be happy to stop there: Or maybe just a little further than that:

These comparisons we can do reasonably quickly and more accurately than we can actually estimate their individual times. So we can begin by setting a baseline.

This is a very small thing: “adding a button”.

In relation to this very small thing: This is a very big thing: “filtering search results”.

Take for example:

We can do these estimates quickly! We don’t find this difficult to do! Over time we’re actually pretty accurate with these comparative or relative measures.

So what’s the point of the story point?

Story points allow us to accumulate measures of relative size into number sets that can be handled more effectively. While one cannot sum a “big” and a “small” together to arrive at a final number if we assigned a ‘Point System’ to each value then we’d be able to do so more easily.

Now if we had sized the stories in a sprint with our team and these had the following size: 2 very small tasks, 3 small ones, 5 medium ones, 2 big ones and 1 very big one.

We’d be able to say:

(2 x 1) + (3 x 2) + (5×3) + (2 x 5) + 8 = 41

And that would be our estimated “velocity” in Story Points for that team!

There are a number of common mistakes I’ve seen teams make that are listed below:

1. Spending too long estimating.
2. Not understanding / sharing / explaining that these are relative measures.
3. Not updating estimates when people are sick or when teams change.
4. Putting too much pressure on the team to reach a certain number of points such that they begin inflating points to meet targets without actually delivering more work.

We could track how many points we actually end up completing each ‘sprint’ or iteration and eventually, for the same team, work out how many points we complete on average.

For example at Nona we’ve dealt with the above mistakes as follows:

1. Too long

• Emphasise that these are instinctual and not to be deliberated for too long.
• Be sufficiently prepared for ticket estimations through doing enough refinement.
• Use a tool like planitpoker to speed things up.

2. Lack of understanding

• Ensure that the full team has a solid education in Agile.
• We recommend the book Clean Agile by Robert C Martin and nearly everyone at Nona has read it.
• Speak about why you are doing each agile meeting often.
• Share responsibility for running meetings with every member of the team to ensure buy in and proficiency with the process.

3. Updating estimates.

• We communicate often and honestly with our clients and within our teams, constantly refining our estimates and letting our stakeholders know how changing situations have impacted these.
• We take a proper look at our sprint half way through and ask ourselves if we’re still on track, if anything needs to change, etc.

4. Too much pressure on the team

• We communicate regularly that points are not the key measure. Real delivered value over time is.
• We have fostered a culture of trust and accountability such that development team members aren’t incentivised to lie about progress or inflate points for any reason.

I usually give it about 3 iterations before a team starts developing a roughly accurate measure of their story point capacity. After that time one can start being reasonably sure of the average.

Great question… Ed…

How do teams often get this wrong?

Each one of these is imminently solvable and have nothing to do with whether story points are a valuable tool or not.

What about the longer term — project length estimates?

Once one has written down all of the requirements for a project one can apply some very loose estimates to ALL the remaining tasks in a project. These are normally not very finely broken down — so the estimates will be in the HUGE or VERY HUGE category.

E.g. Complete payment functionality = 40 points.

Summing everything that remains and dividing by the average points completed in a sprint and then adding a sprint or two for unknowns, changes, cleanup will arrive at what is generally quite an accurate measure of the time remaining in a project to arrive either at the end or at a predefined milestone.

It is worth noting that this estimation becomes more and more accurate over time. As the bigger chunks of work are broken up into smaller pieces, and the team’s velocity becomes more certain, the accuracy of the estimate improves.

This makes it a very useful measure over time for when the project will actually be completed and also serves to clearly illustrate the effect on the timeline of adding or removing features from the roadmap which can make it a great discussion point with your stakeholders about priority and timeline.

Nona helps funded founders accelerate their software projects. If you’d like to soundboard your tech or your team, book a consultation with me and we can chat through it!

So what do you think?

I’d love to hear your opinions on Story Points, how you love or hate them, how you’ve used or abused them? Please get in touch!

If you enjoyed this article I’ve recently written posts on Given When Then and how our stand ups have changed now that we’re fully remote.

Originally published at https://blog.nona.digital on September 28, 2020.