To Estimate or Not to Estimate: A Guide

In the world of Agile development, the use of estimations (either time or Story Points) is a common practice. It’s a tool that helps teams in sprint planning, prioritization, etc. However, the fact we can estimate doesn’t mean we have to estimate — not all activities deserve estimation. In this post, we’ll dive into when to use estimations and when it’s best to keep away from them, focusing on optimizing your Agile process for delivery while minimizing unnecessary overhead.

Why not Estimate

Let’s begin by emphasizing that not all tasks deserve the assignment of estimations. It’s crucial to differentiate between general activities conducted within a sprint and those centered around delivering value. Delivery-oriented activities directly enhance the product under development, such as implementing new features based on stakeholder requirements or refining the product code to maintain our architectural integrity.

In contrast, some activities indirectly contribute to product improvement, like regression testing and release-related tasks. While these activities are essential, they don’t directly add value to the product itself. To illustrate further, even a seemingly unrelated activity like a coffee break can have indirect benefits: it provides opportunities for informal discussions by the coffee machine, allowing us to address and resolve product issues. However, no one would consider assigning estimations to a coffee break.

The ability to estimate various activities doesn’t imply that we should do so. Our primary focus should remain on measuring the direct delivery of value, rather than measuring every aspect of work.

When discussing estimations, it’s important to recognize that excessive estimation can lead to time wastage, as estimation itself requires effort. The critical question to ponder is: what decisions can the organization derive from these estimations? If you believe that the effort invested in estimation can significantly enhance decision-making, then by all means, proceed. In many cases, estimations are used for reporting alone.

Additionally, let’s consider the psychological aspect. If we opt to estimate items not directly contributing to product delivery, it can hide underlying issues, presenting an overly positive picture in our charts. This may reduce the organization’s motivation to maintain a balanced approach between delivery and non-delivery tasks. When not estimating specific types of activities, it drives the teams to minimize or automate those activities.

Moreover, when estimating too many work types on the development side, it is hard to have a clear view of the ratio between the R&D effort invested into the product (i.e. stories) versus the R&D work invested into maintaining the architecture runway (i.e. tasks) — read more here. When we check the ratio between stories and tasks, the hidden assumption is that the general investment in the development pipeline is not being estimated (e.g. release activity, regression activity, etc).

Streams of Estimation

In product development, three primary streams guide our journey: stakeholders’ requirements, internal R&D needs, and the ongoing delivery pipeline. Let’s explore each with a lens of refinement and clarity.

Stakeholders’ Requirements

These requirements shape our path, including a spectrum of functional and non-functional demands such as performance benchmarks, operational adjustments, and research activities to shape future delivery. While some of these requirements seamlessly integrate into our software through direct code modifications, others serve as foundational pillars, supporting our progress through exploration and analysis (e.g. research).

Internal R&D Requirements

Within the boundaries of our R&D region, requirements emerge organically, fostering the evolution of our architectural landscape. Rooted in the spirit of continuous improvement, these demands often appear as refactoring activities and technological research. Though their impact on our software may not always be immediately tangible, their significance lies in protecting the product framework and enabling future stakeholders’ requirements.

Delivery Pipeline (Reoccuring) Activity

The delivery pipeline constitutes an indispensable path that includes routine tasks essential for product delivery. From the structured rhythm of Scrum meetings to the careful processes of deployment and regression testing, each activity represents a pivotal role in sustaining our delivery momentum. Similar to the seamless operation of clockwork, these activities function harmoniously in the background, regardless of the stakeholder’s requirements and internal R&D requirements.

In Conclusion

Looking at the three streams outlined, it is advisable to concentrate estimations on the initial two streams: stakeholders’ requirements and internal R&D demands. On the contrary, similar to the way we avoid estimating our coffee and lunch breaks, estimating the delivery pipeline activity is not recommended. In the following section, we will dive deeper into understanding what is recommended for estimation within these first 2 streams and what is not.

What not to Estimate

We’ve discussed the importance of avoiding estimating work items of delivery pipeline activities. These typically recurring tasks like regression testing, release activities, and similar processes. While looking at stakeholders' requirements and internal R&D requirements, here are some activities that I would recommend not to estimate.

Leftovers from DoD Delivery

Leftovers from delivered items that were almost completed according to the Definition of Done (DoD), should not be assigned with Story Points, as the estimation of the original item already covers the total Story Point. For example:

• Bugs: Defects that surface after a delivery. See more details in the following post.
• Testing-only: The essential but often time-consuming tasks associated with quality assurance and testing, when it is not attached to a specific requirement development.
• Documentation: Creating or updating project documentation.

These are typically not prime candidates for Story Points. They don’t add new value to your delivery but rather address issues that may have arisen during the process. Tracking them with Story Points can muddy the waters and make it challenging to capture your team’s true progress on value-adding work.

Non-Code Contributions

Some activities, while important, often don’t directly contribute to the software code that forms the core of your product. Assigning Story Points to them can reduce transparency on what directly contributes to value delivery and what doesn’t

• Research: Investigative work, such as exploring new technologies or approaches.
• Operational Activity: Activities like modifying production database values or configurations.
• Architecture & Design: design and architecture work of requirements, before those requirements reach the development phase.

Turning Zero Estimation Activities into Opportunities

Rather than estimating these non-value-adding activities, consider strategies to either minimize or eliminate them:

• Operational Stories: Collaborate with product managers to integrate functionality into the product, making it operable by end-users (e.g., finance operations, customer support) rather than relying on R&D to handle operational tasks.
• Research: While some research is necessary, be alert about questioning the level of investment required. Allocate resources thoughtfully and aim for well-defined objectives.
• Release Activity: Automate repetitive release tasks, reducing the manual effort and risk of errors.
• Documentation: Integrate documentation into ongoing content delivery activities. Document the content as you deliver it, making it an integral part of the development process.
• Testing-only: Incorporate testing into the Definition of Done for your content. Ensure that thorough testing is included in your development cycle to prevent post-delivery defects.
• Bugs: Promptly address issues as they arise. Maintain a zero defects policy. Swift action can prevent them from becoming nagging concerns and taking up valuable effort in the future.
• Architecture & Design: Incorporate design work into ongoing content delivery. If there is architecture work for a big requirement (e.g. Epic) before we slice it into sprint-level requirements (e.g. Stories), this is similar to research work that was previously discussed. In many cases, such architecture work is done outside of the development team, by a separate architecture team and not even reflected on the team’s Scrum board.

Translating Delivery Effort to Work Effort

Often, top management requires insights into the time spent on delivery, and when not estimating all work activities, a translation (or normalization) is necessary, as delivery effort represents only a specific portion of our work effort. The translation between delivery effort and total work effort is straightforward.

Here are the guidelines for translating story points to time, on-demand:

1. Determine the total working days for the team in a sprint by multiplying the number of people in the team by the number of days in the sprint.
2. Calculate the average velocity of the team, based on the most recent 3–4 sprints. Include the delivery effort of both the stakeholders' requirements and internal R&D requirements.
3. Divide the total number of working days by the average velocity. The result represents the translation of one delivery day into working days.

For instance, consider a team of 8 people working in 2-week sprints with an average velocity of 35 delivery days. In this scenario, one delivery day equals 2.3 days (8 * 10 / 35). If, 6 months later, the team’s average velocity improves to 40 delivery days, the translation adjusts accordingly, and one delivery day equals 2 working days (8 * 10 / 40). This approach ensures a dynamic and accurate reflection of the team’s evolving efficiency in delivery days to time translation.

Another variation to calculate the delivery vs work ratio is by excluding the vacations, holidays, and sickness days from the equation, by reducing ~20% of the total available working days. Let’s take again the previous example with a team of 8 people working in 2-week sprints with an average velocity of 35 delivery days. In this scenario, one delivery day equals 1.8 days (8 * 10 * 0.8 / 35). This time, the ratio doesn’t include vacations, holidays, and sickness days.

When explaining the gap between delivery days and working days to management, it’s crucial to emphasize that delivery days indicate the actual time devoted to directly enhancing the product’s value. Conversely, translating this into working days becomes essential to reflect the entirety of the work efforts, including those not estimated. This contains a spectrum of activities such as addressing bugs, engaging in release and regression activities, handling production incidents, conducting research, participating in Scrum meetings, attending Epic review sessions, doing knowledge transfer between team members, and more.

Conclusion

In the world of Agile, using estimations wisely can help teams streamline their processes and focus on delivering high-value software. By following these guidelines, you can optimize your Agile efforts and maintain a laser focus on value-adding tasks. Eliminating estimations for non-value-adding activities can lead to a more efficient and productive Agile development cycle, ensuring that your team delivers top-notch results.