Story Point Estimation – Easy Way to Start
Story point estimation is a technique used in Agile project management to replace task estimation in time or money. The smallest tasks are estimated at 1 point and then other tasks are weighed and estimated in accordance with that task.
Whether you are just starting or you have already done estimations using Scrum story points (SPs) you might agree with us that it is very time-consuming to calibrate estimations for the whole team. It takes time, it takes discussions and it takes statistics to influence improvements. This is why we wanted to assist this process by coming up with a story point estimation table.
At Teamhood we think some of it is still unavoidable, but we also think that a well-written estimation table can get your team up to speed in a shorter time. While if you go with proper Kanban Software like Teamhood, you might not need estimations at all, because Kanban can help eliminate such waste.
Real-life example – calibrating and defining points
Below you will find an agile story point estimation table example that has 6 outcomes:
- 1 SP
- 2 SP
- 3 SP
- 5 SP
- 8 SP
- 13 SP
In the proposed example 8 story points are a lot and have the potential to be broken down into smaller work items. While 13 is already too high risk and must be broken into smaller items. Just beware – breaking down large items as 13 points, should not mean that two items of 8 SPs and 5 SPs will remain… Story points math is a bad practice.
Each broken-down item should be estimated again individually evaluating the amount of work needed. Thus the result might be three items of 5 SPs each after breaking down one item of 13 SPs.
Lastly, story points are not the only true way to estimate. Read more about different Agile estimation techniques such as the Fibonacci sequence.
Story point estimation table
Disclaimer: by using this table we do not propose to convert story points into time or vice versa. The main goal is to have a faster calibration of estimations for Teams who got recently assembled or just started doing Scrum. To dive deeper into what is story points, how they are measured, and why time as work effort can still make sense, we suggest watching the legendary presentation on Story Points by Mike Cohn from Google.
If you are interested to learn more about why it is important to break down large user stories or epics, read this post. What is more, if you are not sure what the reasons behind different aspects which involve story point size as we used Dependencies, Unknowns, and Work effort, dive deeper by reading about what impacts work item size.
Story point estimation problems?
While there are many various significant issues, based on our and our customer’s experiences, here are the top 3:
- Mapping story points directly to time/hours. Time effort is only a part of the complexity formula, hence it should not be directly mapped. Though naturally, it seems that longer duration means more complexity.
- Miss alignment between team members. This usually can be solved by planning poker and calibration sessions.
- Allowing high/complex effort estimations. This can be solved by forcing a breakdown of a certain size. Doing it will make sure you are better at refining work items as well as reducing not delivering large pieces of work during the sprint.
No estimations: How to do it?
There is a significant trend among the Agile community suggesting moving away from estimations. One must be careful and learn about noestimations thoroughly before diving into it with a team.
How to make estimations efficient?
Simply – get better at it. Then when you feel that you have reached human limits, turn to tools. For example, Teamhood uses Artificial Intelligence (AI) to streamline the estimation of similar items.
Artificial intelligence for automatic estimations
You can save time during task estimation by using the Teamhood intelligence layer. The Teamhood intelligence layer will try to predict task estimates either in hours or story points based on historical data. (depending on your workspace settings).
At first, it might take some time while the engine learns but from a certain point, it will suggest estimations for high-confidence predictions. We are also constantly fine-tuning the engine to increase the amount of time saved for everyone!
Agile software for your Agile team
Automatic estimations, Backlogs, Sprints, Swimlanes, Expanding User stories.
2019 - Present Co-founder and CEO @ Teamhood.
2015-2019 Head of software engineering department at Danske Bank.
2017-2018 Partner Associate Professor at Vilnius University. Lecturer of Software Architecture course
2011 - 2015 Managed numerous smaller IT teams at Prewise.
Co-founder of RaveIT, Eylean, No Brakes Games
Certified Agile product owner and practitioner. Managed large scale enterprise projects as well as launch of small startup products.
MSc of Software Engineering at Vilnius University.
Hobbies: Racing, MTB cycling, Windsurfing
