To Estimate or Not?

The Controversy of Estimates in Agile Software Development: A Balanced Perspective

In the ever-evolving world of Agile software development, the practice of estimating has become a subject of heated debate. While some teams swear by the precision and predictability that estimates provide, others argue that they can be a hindrance to creativity and flexibility. Let's delve into the nuances of this controversy.

When NOT to Estimate

1. Early Stage Exploration: When a project is in its infancy, and the requirements are ambiguous, estimates can be misleading. They may lead to false expectations and unnecessary constraints.
2. Highly Innovative Projects: In environments where innovation and experimentation are paramount, rigid estimates can stifle creativity. The focus should be on learning and discovery rather than meeting specific timeframes.
3. Matured Products with Stable Teams: If a team has a consistent track record of delivering at a predictable pace, estimates may become redundant. The team's velocity itself becomes a reliable indicator.

When to Estimate

1. Client Expectations: When working with external stakeholders, providing estimates can be essential for aligning expectations and building trust.
2. Large and Complex Projects: For projects that involve multiple teams and complex dependencies, estimates help in planning and coordination.
3. Regulated Environments: In sectors like Healthcare, Banking, or Government, where compliance is key, estimates provide a structured approach to project management.

How to Estimate: Tailoring to Team Context

1. Story Points: Attempting to use points for prediction and communication is where they become unreliable in achieving the overall intent of software estimation.Based on the team completing stories that amount to a relative complexity number of 28 per sprint, with a relative complexity number of 198 remaining we anticipate completing the remaining stories in 7 sprints.When read with a charitable amount of skepticism the above statement seems hand-wavy. We have subjectively calibrated relative complexity numbers that are summed, averaged, and extrapolated to estimate a completion date.Take a moment and consider what it means for one story to be twice as complex as another. What about three times more complex? Or even a golden ratio more complex??Complexity and effort are notoriously difficult to quantify, let alone quantify objectively, and we tend to rely on more subjective reasons for justifying point values.Person 1: This story feels more risky because it was hard the last time we worked on a similar story. I feel that moves it from a three to a five.Person 2: Now that we know which rabbit holes to avoid I feel that it should actually be a two-pointer. Our lessons learned make it less risky this time around.? Do you estimate effort or complexity?? What about bugs?? Is one story point equal to one day of work or some other time-based unit?? If not, why do we use it to predict the scope of an iteration that has a fixed duration of fourteen days?
2. T-shirt sizing: An even more abstract method

The above chart is one I’ve used in the past to help plan sprints. By using this chart we see either a story is sufficiently small and sufficiently well understood that we can attach a Small or Medium label to it, or it’s too large and needs to be broken down into well-understood parts, or we need to spend time further clarifying the work.

Ownership

Whoever is working on the story owns the story including breaking it down if it’s too large, asking questions if it needs clarification, or estimating whether it is Small or Medium. Of course, none of this pre-work necessarily needs to be done in a vacuum, and team members are encouraged to bring in help and additional perspectives.

1. No Estimates: A growing movement advocates for focusing on delivering small, valuable chunks of work without traditional estimation. This approach emphasizes continuous delivery and responsiveness.
2. Daily Committable Work

When planning and executing on a sprint the goal is to identify work small enough that it can be scoped to about a day. As each day passes we should expect to see this daily work move across the board, thus communicating to stakeholders and the rest of the team a good sense of progress on the sprint.

Key points:

? Embrace two-dimensional estimates

? Ask the person(s) doing the work to own the work and provide estimates

? Break work down into daily committable tasks to confidently communicate daily progress

? Lastly, empathetically communicate overall progress and expectations through frequent and open conversations with your team’s stakeholders

1. Monte Carlo Simulations: For those who want statistical rigor, Monte Carlo simulations can provide probabilistic forecasts based on historical data.

Measuring Stories

Break our stories down into tasks. The goal with tasks is not to slice our stories into same-sized units like “takes 1 hour of work”. Instead, we use our tasks to break stories down into their natural, smallest units. That means that one task may only take 30 minutes, and another one might take a whole day. A task is a logical unit of the story, can be worked on independently, and is actionable.

Case Study

In some of my previous roles, we experimented with a #no_estimates approach to sprint planning. After finding it to be successful we thought we'd tried to apply it to other departments and processes as well. At CompanyA and CompanyB, we used OKRs to align our team’s goals with the company and other teams. We previously spent a lot of our OKR planning time trying to come up with estimations to limit our workload for the upcoming quarter. We compared the progress we made toward our OKRs when we used estimations vs. when we did not, and the results were almost exactly the same.

So, out with the estimations and in with the #no_estimates approach! We calculated the average amount of key results achieved over the last few quarters and used this number as our guide to set goals for the upcoming quarter. Since our key results are mostly deliverables, we now have a much better idea of how many features we will be able to release. Looking at the data (quantitative and qualitative) plus hard facts helped us to make quick decisions and reduce our overly optimistic commitments.

What did we learn from this?

With this simple experiment, we proved to ourselves that we should always question our processes. Story points are such a widely accepted concept that we automatically accepted its relevance for us. While we can not say that story points have no merit, we learned that, for our team, in that situation, it was not the right tool.

Certainly, Sid! Here's an elaborated section focusing on the various roles within a tech startup that might need estimations, along with different types and methods, including roadmaps and their varying fidelities.

Who Might Need Estimations in a Tech Startup?

Estimations in a tech startup are not confined to development timelines; they permeate various aspects of the organization. Here's a detailed look at who might need them and how they might be applied:

1. Founders and Executives

• Strategic Planning: High-level roadmaps with low fidelity can guide long-term vision and alignment with business goals.
• Fundraising: Detailed financial estimates and growth projections are essential for attracting investors.

2. Product Managers

• Feature Prioritization: Utilizing methods like Weighted Shortest Job First (WSJF) to estimate value and complexity.
• Product Roadmaps: Creating roadmaps with varying fidelities, from high-level thematic roadmaps to detailed feature-level plans.

3. Development Teams

• Sprint Planning: Using story points or t-shirt sizing for sprint-level estimation.
• Technical Debt Management: Estimating the effort required to address technical debt can guide refactoring decisions.

4. Investors and Stakeholders

• Transparency: Providing probabilistic estimates or confidence intervals to communicate uncertainty and risk.
• Alignment with Milestones: Creating milestone-based roadmaps with medium fidelity to track progress against strategic goals.

5. Marketing and Sales Teams

• Campaign Coordination: Estimating product release timelines to align with marketing initiatives.
• Sales Forecasting: Utilizing historical data and market analysis for sales projections.

6. Customer Support and Success Teams

• Resource Allocation: Estimating support needs based on product releases and customer growth.
• Customer Onboarding: Creating roadmaps for customer integration and success planning.

Types and Methods of Estimations

1. High-Fidelity Estimations: Detailed and precise, often used for short-term planning, sprint commitments, and financial projections.
2. Medium-Fidelity Estimations: Balancing detail and flexibility, suitable for quarterly planning, milestone tracking, and resource allocation.
3. Low-Fidelity Estimations: Broad and thematic, used for long-term strategic planning, vision setting, and high-level road mapping.
4. Probabilistic Estimations: Providing a range of outcomes to communicate uncertainty, often used with external stakeholders and for risk management.

Conclusion for Startups

In the dynamic environment of a tech startup, estimations serve diverse needs across the organization. From guiding the strategic vision to aligning day-to-day operations, the types and methods of estimation must be carefully chosen to resonate with the startup's culture, stage of growth, and market demands.

By embracing a multifaceted approach to estimation, tech startups can navigate the complex landscape of innovation and growth with agility and confidence. The key is not in seeking absolute precision but in finding the right level of fidelity and method that empowers decision-making and fosters alignment.

Estimation in Agile is not a one-size-fits-all practice. The decision to estimate, how to estimate, and even whether to estimate at all must be tailored to the team's context, the nature of the project, and the broader organizational culture.

By embracing a flexible approach to estimates, we can foster an environment that balances predictability with innovation, alignment with autonomy, and planning with adaptability.