How to use story points to estimate software

One of the main challenges in software planning is how to estimate work amounts. At UnSeen, we use scrum as our development methodology and in sprint planning, we use story points and planning poker to estimate SW complexity.

Main benefit of story points is that they allow people with different skill levels to discuss and agree how complex a certain task is. This is possible since we are not trying to estimate how long it will take to implement something. Instead, it is estimated how complex a certain task is, and what is the relative complexity compared to other tasks in the backlog.

Think about running a certain distance, say 10 kilometers. It is straightforward to estimate the complexity of the task (that’s 10 km). On the other hand, estimating how long it will take someone to run that distance depends on the skill level of the runner (how fast he/she can run) and can be widely different for two people. Trying to agree an estimate on “how long will it take” is not possible before it is known who will be doing the running.

With story points, the skill levels of team members are not impacting the estimates. In our experience, this greatly speeds up the estimation process.

This is how we do it

At the very first sprint planning, a baseline story is selected. It serves as a common reference point in the following discussions throughout the project.

For a web application, a simple user story which still requires both front end and back end implementation is a good selection for a baseline story. This baseline gets 5 points. A story with only a small front end visual change could be 1 point, and more complex stories obviously get more than 5 points.

The values we use are 1, 3, 5, 7, 10, 15, 20 and 25. Any story with 25 points will have to be split to smaller tasks before it is taken into sprint content.

We use physical cards when voting for points. We have modified couple of regular playing card decks by adding home-made 15, 20 and 25 cards. You can go as fancy as you like but we like to keep things simple. This low tech approach works well.

After the baseline story has been selected and everyone has cards, estimation can start.

Product owner explains the user story and people can ask questions. When everyone is ready with no more questions, there is the first voting round. The cards are revealed simultaneously. This way people do not influence each other’s estimates.

People who voted for the lowest and highest points explain briefly why they selected these values. After this, everyone votes for the second time, taking into account any new information they learned from the discussion. Cards are again revealed simultaneously.

Usually there is much less variation in points on the second voting round. Most of the time the highest score can be selected as the estimate, or the points that most of the people have voted. Team will discuss until they agree on the estimate.

You should do it, too

Story points and planning poker are an easy way to estimate SW. If you have not estimated SW complexity before, they are a good starting point and will improve your planning compared to no estimates at all. After a couple of sprints, you’ll have experience and can modify your practices to increase team effectiveness.