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.
Either you are just starting or you have already done estimations using 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.
Below you will find an agile story point estimation table which has 6 outcomes: 1,2,3,5,8,13 story point. 8 story points are a lot and have a potential for being 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, such can result in three items of 5 SPs each after breaking down one item of 13 SPs.
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 are the reasons behind different aspects which involve story points size as we used Dependencies, Unknowns, Work effort, dive deeper by reading about what impacts work item size.
Story point estimation problems?
While there are many various significance issues, we recognize based on our and our customer experience the top 3:
- Mapping story points directly to time/hours. Time effort is only a part of 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 from certain size. Doing it, will make sure you are better at refining work items as well as reducing of not delivering large pieces of work during sprint
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 estimation of similar items.
Artificial intelligence for automatic estimations
You can save time during task estimation by using Teamhood intelligence layer. Teamhod intelligence layer will try to predict task estimate 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 certain point it will suggest estimations for high confidence predictions. We are also constantly fine tuning the engine to increase amount of time saved for everyone!