What’s the Story Point?

What are story points and how can they help with Software Development.

Estimation

Anyone who have been involved in software will have given an estimate at some point. We are all used to estimates and typically these are given in time using an appropriate unit, 1 hour, 3 days, 2 weeks, 6 months. Time estimates are great when you have some idea of certainty and when the same person is doing the work.

Example. I can fairly accurately estimate how long it will take of me to clean the house, I know this from experience, I have done it before, the task dosen’t really change in terms of size or complexity. However, my estimate is usually much lower than my wife’s (not being drawn in on this one) – so there are 2 things to consider.

1. It’s fairly easy to estimate a non-complex, repeatable task based on past experience
2. Estimates will vary depending on who is doing the work

The Problem Estimating Software

In Software Engineering, it is rare to be doing non-complex, repeatable tasks (if you are why?). Software Development typically involves solving of complex problems, not simple ones and Software Engineering is a process of discovery, you are teasing out requirements, trying, learning and at times failing. There are a lot of unknowns. All developers have been hit by an unanticipated problem, maybe with a 3rd party library, or dependency on a framework you didn’t know was going to be an issue – the unknown unknowns.

Every developer is different! What might take one developer 2 days, could take another 3. This does not correlate to seniority either. All devs are different and all days are different. Refer to book, ‘The Mythical Man-Month’ by Fred Brooks, and older book, but very relevant still to this day.

Consider this statement.

“It will take 1 day to complete the feature” – A Developer

Now, does that mean if started on Monday it will be ready on Tuesday? What if on Monday, there is a 2 hour refinement session and then a 1 hour team meeting? There is a difference between elapsed time and duration. It may take 8 hours of dev, but that may span 3 days to fit in with other commitments.

While time is a valid unit of measure for Software Development, a different approach to consider is Story Points.

What Are Story Points?

Story points are a unit of measure providing a way to size a given piece of work relative to another. Humans are generally bad at estimating, that is no secret, but we are quite good at comparing things. When estimating a new feature, compare its relative size to another story previously done.

Story Points are made up of 3 elements;

It’s important to consider all 3 in an estimate.

Complexity

Complex tasks by their nature may take a long time and have more risk such as unforeseen complications.

Uncertainty/ Risk

A task may seem easy or understood, but maybe there is a lot of risk or uncertainly attached that could seriously affect delivery time. Maybe an assumption has been made that doesn’t hold true or the 3rd party library doesn’t quite work the way we thought.

Effort

Amount of effort covers tasks that are well understood, possibly easy to do, but just required a lot of effort to complete. They might take as much time to do as a complex task, which will impact how many of these types of tasks can be completed in an iteration.

Point Sequence

A common scale is based on the Fibonacci sequence (up to 13), but any scale will do, as long as you stick to it and can compare sizes relatively.

1, 3, 5, 8, 13, 20, 40, 100, ?

A story might start out as 40, then through refinement be split out into a number of smaller stories that may or may not add up to 40, usually things get bigger when you add more detail.

Use the question mark when you really don’t know, and that’s ok! Its a trigger for a conversation and/or a design spike.

Velocity

The idea of points is to get a stable velocity – How much work can a given team achieve in a specific period of time? This can be used as a planning tool. If a team has an average velocity of 40 points per sprint this can be used to predict how long a product or set of features will take. It’s important to use an average and record and adjust this over time as sprint 1 may have all team members present, but sprint 2 there maybe holiday or sickness, so it has to be an average. The velocity takes into account meetings and time spent on other activities such as support, anything that does not directly relate to feature development. I will cover velocity in depth in a future post.

Velocity is time spend delivering new features. Other activities in the sprint will happen, but will not contribute to velocity.

In the above example, velocity goes up and down depending on several factors (holidays, training etc), but the power is knowing a team on average can deliver 40 points of value per sprint. This allows forecasting and release planning to take place with a degree of confidence. It’s important to track this metric and adjust schedules over time.

Golden Stories

When creating an estimate using points, the idea is to compare to a story previously done. A team should identify a previously achieved piece of work (golden story) for each point value. When estimating you can cross-reference this and ask, is this new story smaller or larger than a say an 8? Refer to the 8 point golden story to compare (based on effort, complexity and risk). This is a great way to get confidence. Usually it’s fairly easy to say if a story is smaller or larger by using comparison, much easier than putting a time estimate on it. Move up and down the scale as required to find the approximate size. If in doubt, go higher and do some more work such as a design or proof of concept.

Breaking a Story into tasks

For large stories, it often helps to break it down into sub-tasks to identify all the steps required. This can create more accurate estimates to ensure nothing is overlooked. From this it may also be possible to split a story into several smaller stories.

The law of small numbers

You will be out on estimates, it’s inevitable, that’s why they are estimates and not commitments. If you have one or two large Stories, this will be very noticeable. Having lots of smaller stories allows the possibility for differences to average out, some stories will be over, some under, but overtime this has more chance of averaging out than a few large stories.

To get better at estimating it may help to try and make all stores roughly the same size.

Planning Poker

This is a well know technique where developers show a card with a number for their estimate, if all the team agree, that’s the estimate. The power here is when people don’t agree. If someone says a 3 and another a 13 then have a discussion, where are the gaps in understanding?

All Developers should reveal their estimate at the same time, it can be an anti-pattern to reveal scores in turn as it may influence another persons selection and people can’t be complacent and just follow the one before. Create an environment where people feel free to give a genuine estimate without fear. The goal is shared understanding. You don’t all have to agree to reach an estimate, but there should be an appreciation of what’s involved. If in doubt pick the higher number or an average. Also remember estimation is not a one time activity, you can and should re-estimate a story as your learn more over time.

Key Points

Story points work well with stable, long lived teams. Practice it, stick with it and it will become easier.

• Story points do not equate to time! (If you convert to time, why not just use time instead!)
• Points are not comparable across teams – a teams’ velocity is unique to that team only
• Story points are made of up effort, complexity and risk
• The team that does the work, does the estimate – simple!
• Update the estimate as your refine, learn and breakdown a story
• For large stories do a design spike, spend some time on the design