Estimation is a complementary practice Scrum Teams use in Product Development. The purpose of estimation is to provide a rough idea of how much effort, time, and budget are needed to complete specific features or PBI- Product Backlog Item of the product. Estimation may also help with planning, ordering backlog, and tracking the progress of the work.

Estimation can help the Product Owner decide to build a feature now next, next, later, or never. This may be one of the points product owners may consider while deciding about the desirability and viability of the feature.

However, estimation is not an exact science, and there are many challenges and uncertainties involved in it. Different Scrum Teams may use different estimation approaches, depending on their context, preferences, and goals.

Let’s explore some of the complementary estimation approaches used by Scrum Teams, and discuss their pros and cons.

📊Relative Estimates (Story Point Estimates)

Story point estimates are one of the most popular estimation approaches. Story points are a relative measure of the size and complexity of a PBI-product backlog item, which is a small, valuable, and testable piece of functionality. Story points are usually assigned by the team members using a scale such as the Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.) or T-shirt sizes (XS, S, M, L, XL, etc.). Some other teams may use animal sizes (Rat, Cat, Dog, Horse, Elephant etc.) or any other relative sizing techniques. The team then uses the total number of story points in a sprint (a fixed time box, maximum a month long) to calculate their velocity (the average number of story points completed per sprint). The velocity can then be used to forecast how many sprints are needed to complete all the items in the product backlog (the list of all PBI- Product Backlog Items).

Advantages of Story Point Estimates:

The main advantage of story point estimates is that they are easy to use and understand, and they avoid the pitfalls of using time-based estimates, such as over- or under-estimating, Parkinson’s law (work expands to fill the time available), and student syndrome (delaying work until the last moment). Story points, if used well, also allow the team to focus on the value and quality of the work, rather than the hours spent on it.

Drawbacks of Story Point Estimates:

However, story point estimates have some drawbacks, such as:

• They are subjective and may vary from team to team, or even within the same team over time.

• They require a lot of calibration and refinement to ensure consistency and accuracy. Teams may fall into the trap of converting story points to hours or days.

• They may not reflect the actual effort or duration of the work, as they do not account for factors such as complexity, dependencies, risks, technical debt, learning curve, etc.

• They may create a false sense of precision or certainty, and lead to unrealistic expectations or commitments.

🕰️ Absolute Estimates (Hourly/Days Estimates)

Hourly or days estimates are another common estimation approach used by teams. As the name suggests, this approach involves estimating the amount of time (in hours or days) needed to complete a PBI-Product Backlog Item. The team then uses the total number of hours or days in a sprint to plan and track their work. This approach generally be least useful for complex product development.

Advantages of Hourly or Days Estimates:

The advantage of hourly or days estimates is that they give a (false) sense of being more concrete and tangible than story points, and they can be easily translated into costs, budgets, and deadlines. In some cases, hourly or days estimates may also help the team to identify and manage the dependencies, risks, and uncertainties in the work.

Drawbacks of Hourly or Days Estimates:

However, hourly or days estimates have some drawbacks, such as:

• They are prone to errors and biases, such as optimism or pessimism, anchoring or adjustment, planning fallacy, etc.

• They may create a pressure or incentive to work faster or slower than the optimal pace, and compromise the quality or value of the work.

• They may not reflect the actual value or complexity of the work, as they do not account for factors such as creativity, innovation, collaboration, etc.

• They may create a culture of micromanagement, finger-pointing, throwing over the fence or blame, and considerably reduce the autonomy and trust of the team.

• They may lead the Scrum Team to spend too much time to come to an exact estimation of hours or days.

📈 Probabilistic Estimates (Flow Metrics Estimates)

Flow metrics estimates are a relatively new and emerging estimation approach used by teams. Flow metrics are quantitative measures of the flow of work through the system, such as cycle time (the time from starting to finishing a PBI-Product Backlog Item), throughput (the number of PBI completed at a specific time period), work in progress (the number of PBI being worked on at any given time), etc. The team then uses the historical data and trends of these metrics to forecast the future performance and outcomes of the work.

Advantages of Flow Metrics Estimates:

The main advantage of flow metrics estimates is that they are based on actual data and evidence, rather than assumptions or guesses. Flow metrics estimates can also help the team to monitor and improve their efficiency and effectiveness, and to identify and eliminate the bottlenecks and waste in the system.

Drawbacks of Flow Metrics Estimates:

However, Flow Metrics estimates are also not perfect and have some drawbacks, such as:

• They require a high level of maturity and discipline from the team to collect and analyze the data accurately and consistently.

• They may not capture the qualitative aspects of the work, such as customer satisfaction, user feedback, business value, etc.

• They may not account for the variability and unpredictability of the work, as they assume a stable and linear system.

• They may create a dependency or reliance on the data, and ignore the intuition, and judgment of the team.

🚫No Estimates

No estimates is a radical and controversial estimation approach used by Teams. No estimates mean that the team does not do any estimation at all, and instead focuses on delivering the highest value and quality work in the shortest possible time. The team then uses the feedback and learning from the work to adapt and improve their process and product.

Advantages of No Estimates:

The main advantage of no estimates is that it eliminates the overhead and waste of estimation, and frees up the time and energy of the team for more productive and creative work. No estimates also encourage the team to embrace uncertainty and change and to experiment and innovate.

Drawbacks of No Estimates:

However, no estimates also have some drawbacks, such as:

• They may not meet the expectations or requirements of the stakeholders, such as customers, managers, investors, etc., who may need or demand some form of estimation for planning, budgeting, or reporting purposes.

• They may not provide enough visibility or transparency into the progress and status of the work, and make it difficult to communicate or collaborate with other teams or parties.

• They may not support the prioritization or decision–making of the work, and make it hard to compare or evaluate different options or alternatives.

• They may create a lack of accountability or responsibility for the outcomes and impacts of the work, and make it hard to measure or improve the performance or results of the team.

Example to illustrate how different estimation approaches can be applied.

For example, suppose you are working on an airline mobile app that allows users to book flights, check-in, access boarding passes, track bags, and access inflight entertainment. How would you estimate the work involved in developing this app using different estimation approaches?

• Story point estimates: You could use story points to estimate the relative size and complexity of each PBI-Product Backlog Item or feature, such as “As a user, I want to search for flights by date, destination, and price”, or “As a user, I want to watch movies and TV shows on my device during the flight”. You could use a scale such as Fibonacci sequence or T-shirt sizes to assign story points, and then use the team’s velocity to forecast how many sprints are needed to complete the entire Product Backlog Items.

• Hourly or days estimates: You could use hours or days to estimate the amount of time needed to complete each PBI-Product Backlog Item or task, such as “Design the user interface for the flight search screen”, or “Implement the API integration for the baggage tracking feature”. You could use historical data, expert judgment, or estimation techniques such as three-point estimation to determine the hours or days, and then use the team’s capacity to plan and track the progress.

• Flow metrics estimates: You could use flow metrics to measure and forecast the flow of work through the system, such as cycle time, throughput, and work in progress. You could use tools such as Kanban boards, cumulative flow diagrams, or control charts to visualize and analyze the data, and then use statistical methods such as Monte Carlo simulation or Little’s law to predict the future performance and outcomes of the work.

• No estimates: You could use no estimates to focus on delivering the highest value and quality work in the shortest possible time, without spending time or effort on estimation. You could use techniques such as user feedback, value stream mapping, or hypothesis-driven development to prioritize and validate the work, and then use practices such as continuous delivery, test-driven development, or pair programming to deliver and improve the work.

🌟 Conclusion

As we have seen, there is no one-size-fits-all estimation approach for Scrum Teams. Each approach has its own strengths and weaknesses and may suit different situations and contexts. The best estimation approach for a Scrum team depends on many factors, such as the nature and scope of the work, the maturity and experience of the team, the expectations and needs of the stakeholders, the goals and objectives of the product, etc.

Therefore, Scrum Framework doesn’t prescribe any specific approach for estimation. The Scrum team should not blindly follow or adopt any estimation approach, but rather experiment and evaluate different approaches, and find the one that works best for them. The Scrum team should also be open and flexible to change or adjust their estimation approach as the work evolves and the environment changes.

🤜🤛 Remember, “Estimates Are Not Commitments“. 

While these estimation approaches may be helpful for the Scrum Teams:

In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.

I hope this article has given you some insights and ideas on how to estimate your work as a Scrum team.

I would love to hear from you, which estimation approach are you using and what benefits do you achieve?

Please share your thoughts and experiences in the comments below.

Thank you for reading!