If you have heard even a little about story point estimations, you would know that it does not represent the time taken to complete a story.
If that’s the case, you might be surprised to know that story points did originate from time estimates. Ron Jeffries talks more about how story points came about.
While many advocate the futility of estimations, especially how most teams and businesses do it, estimations are still part of your professional life. It is better to learn to do story point estimations better if that’s the case. This article discusses many best practices you can employ for such estimations.
Table of Contents
Many Ways To Estimate
Software development teams have employed various estimation methods, from simple expert estimates (subjective) and analogous estimates (based on historical data) to more elaborate methods like parametric estimation and function point estimations.
With the adoption of agile methods, the focus shifted to relative estimates. From simple t-shirt sizing, where the user stories or product backlog items (Scrum) were divided into multiple buckets of complexities, to using the Fibonacci Sequence to assign the point value, there is still a variety of estimation methods that teams use.
Irrespective of how you estimate, some foundational aspects are true for better estimates. These aspects are the central point of discussion for this article.
Characteristics of Story Point Estimations
Story point estimation is relative.
The story points have no meaning when considered in isolation. Knowing that a story has 10 points is only valid when there is another story to compare.
Story point estimation is relative, based on comparing one story to another. This relativity means that when estimating a story, you should consider how it compares to other stories in terms of complexity and the effort required. For example, if you have two stories with similar complexity, but one requires more effort than the other, then you should give the story requiring more effort a higher story point estimate.
Before you start estimating stories, it is essential to establish a baseline. You can do this by taking an average of the story points given to similar stories in the past. This baseline will provide you with a good starting point for your estimations.
Story point estimates do not represent time.
Since it is relative, it can represent any other single dimension of the estimate, including time.
Story point estimates do not represent time. Story points measure complexity and effort rather than the time it will take to complete a task. This approach is because story points are relative and can vary depending on the team’s experience level, the size of the project, and other factors. As such, you should not use them to measure how long it will take to complete the work.
It doesn’t represent capabilities or efficiencies.
Story point estimations do not represent the capabilities or efficiencies of a team. It is important to remember that story points are relative and do not reflect the actual capabilities of a team. A team may be able to complete a story with 10 points in less time than another team, but this does not mean that the first team is more efficient or capable than the second.
Best Practices for Story Point Estimations
Slice the work into the smallest possible stories.
The best estimates come when there is enough clarity about the work. As the size of the user stories or a product backlog item is large, the chances are that the team will not be able to uncover all the hidden complexities. However, the complexities and unknowns start getting revealed as you break the work into smaller chunks.
Once such complexities are uncovered, teams can take appropriate action to get clarity. Then, even when assumptions still need to be made, the adverse impact of the assumptions getting invalidated over time reduces.
When estimates take into account the unknowns, they tend to get better.
It should be done by the people who will do the work.
It is easy for anyone to estimate standard, repetitive work. These estimates are derived from the experience of doing the same work over and over again many times. One can estimate such work even for others.
However, complex work will almost always be unique. The context changes, the requirements change, and people and situations change. Even with repeatable work, specific changes, like better tools and improvements in software development languages, may change the estimations significantly. The skill and the resources available to those doing the work determine the efforts required to finish the work; hence, they are the ones doing the estimations.
There are techniques like planning poker during Sprint Planning that allows you to tackle the biases and experiences or lack thereof of a single person estimating the work when you involve the entire team. The team effort also ensures accountability and helps you with better estimates.
Bring the work closer to estimates.
The work that is too far in the future is hard to estimate. You may not require the work itself in the future. Generally, when the work is to be done immediately, it is clearer for everyone on the team. Also, it reduces the risk of the assumption getting invalidated, impacting the estimates negatively for future stories.
Make the estimation process and technique consistent.
Consistency is vital when it comes to story point estimations. Estimations should be done using the same technique and process across all stories to make the estimates comparable and meaningful.
It is essential to use a consistent scale when estimating story points. This consistency will ensure that everyone is on the same page regarding understanding the complexity of stories.
It is crucial to ensure that everyone involved in the estimation process understands the technique and how it works. In addition, this involvement will help ensure everyone is on the same page regarding estimating stories.
As your team gains experience, you should re-estimate stories regularly to ensure they are still accurate. This effort will help keep your estimates up-to-date and relevant.
Make the estimation process and results transparent.
Making the estimation process and results transparent is essential for successful story point estimations. It helps to ensure that everyone involved in the estimation process understands how the estimates were arrived at and why you made certain decisions.
Transparency also helps to build trust between team members, as it allows them to see how their input was taken into account when making estimations. This transparency can help reduce potential conflicts that may arise due to differences in opinion.
Advantages of Good Estimates
Good estimates are essential for successful project management. They provide a basis for planning and budgeting, as well as help to ensure that resources are allocated appropriately. Reasonable estimates also help to reduce the risk of projects going over budget or taking longer than expected, as they provide an accurate picture of the work that needs to be done and how long it will take.
Reasonable estimates also help teams set realistic goals and timelines, as they clearly understand the project’s scope and how long it will take to complete. This visibility can help teams deliver projects on time and within budget.
When Should You Not Bother With Estimates?
Regarding story point estimations, specific scenarios may not be worth estimating. For example, it may not be worth evaluating if the work is too small or too far in the future. Additionally, if the work is too complex or uncertain, estimates may not be reliable and could lead to inaccurate results.
In these cases, it may be better to focus on actually doing the work and shorten the feedback loop to learn more about the details of the work and understand all challenges and complexities.
Conclusion
Finally, it is essential to remember that story point estimations are not an exact science. They are based on assumptions and estimates and should be treated as such. The best way to ensure accurate estimations is to use the best practices outlined above and to continually review and refine the estimation process as needed.
