The Purpose And Perils Of Time-Based Estimates In Agile

The Flaws of Time Estimates in Agile

Time estimates have been a central part of software development methodologies for decades. Traditional waterfall projects place heavy emphasis on upfront time and cost estimates as the basis for projects plans, budgets, and contracts. The rationale is that with detailed requirements and design completed early, developers should be able to accurately gauge the effort and duration of programming and testing activities.

Agile methodologies such as Scrum and Kanban aim to provide more flexibility and adaptability in software projects, favoring iteration and incremental delivery over rigid upfront plans. However, time estimates do still play a role in Agile processes for planning iterations, measuring team velocity, and forecasting project delivery timelines.

This continued reliance on time estimates is concerning, as research shows that they are flawed in several aspects:

• Humans are inherently poor at estimating software tasks due to cognitive biases
• Unknowns and complexity make accuracy improbable
• Focusing on estimates incentivizes bad behaviors
• Emphasis on speed reduces software quality

This article examines the shortcomings of using time estimates as a core planning technique in Agile, and puts forward alternate metrics and process changes that lead to better project outcomes.

Overestimating Leads to Lack of Accountability

A common argument for creating detailed time estimates on Agile projects is that they provide accountability. By committing to completing a set of user stories or features within a particular iteration, the team is held responsible for delivery.

However, when teams chronically overestimate tasks, this accountability is lost. Several psychological factors lead to teams padding estimates consistently:

• Fear of not meeting commitments
• Lack of historical data on new project elements
• Cognitive biases causing inflated guessing

While reasonable contingency may be included, excessive overestimation enables teams to meet estimates without stretching themselves. There is no impetus to improve skills, tools, or processes.

Further, product owners lose the ability to determine realistic scope based on inflated estimates. The net result is a lack of accountability from both the team and product perspective.

Underestimating Causes Unrealistic Deadlines

In contrast, when teams underestimate, an unrealistic deadline emerges. While agile processes contain various feedback loops to reset scope based on emerging velocity data, the initial product roadmap is often still presented as a hard target.

As a natural human tendency, teams feel compelled to meet stated deadlines and targets, even when there is inadequate time to complete work at an acceptable quality level. This leads to negative behaviors including:

• Cutting corners on testing
• Increasing technical debt through quick and dirty solutions
• Employing inexperienced resources to meet headcount needs
• Developer burnout from excessive overtime

The net effect is compromised software with more defects and reliability issues down the track.

Estimates Restrict Flexibility and Learning

A key tenant of agile is embracing change. Teams must continuously adapt and pivot as they better understand customer needs through regular feedback loops.

However, embedded time estimates constrain change as they set expectations around scope delivery in particular iterations. While agile processes contain prioritization mechanisms, there remains friction in moving across planned work.

Further, teams get less opportunity to implement process improvements within iterations if the deadline focus is on meeting pre-determined estimates.

As an alternative, removing prescribed estimates affords more flexibility to adapt scope and processes to maximize customer value.

Time Estimates Reward the Wrong Behaviors

Because time estimates are used as a core progress and performance measure on agile projects, they indirectly incentivize the wrong behaviors from teams:

• Pushing for stories that can be completed fastest rather than those delivering maximum customer value
• Breaking down work into smaller pieces to appear more productive from an estimates perspective
• Making unnecessary architectural changes to meet current estimates rather than optimizing for the long-term
• Stopping work when hitting estimate targets rather than delivering to the level of quality the customer needs

Developers are motivated to game the system because their engagement, promotion, and rewards are tied to meeting estimate targets consistently.

Focusing on Cycle Time Improves Flow

If time estimates are not an effective tool for planning and tracking agile projects, what alternatives metrics could be used instead? One candidate is cycle time.

Cycle time measures the average time it takes from starting work on a user story or feature request to completing development through to production deployment. Moving focus onto cycle time improves development flow in several aspects:

• Smooths workload by reducing work-in-progress queue lengths
• Forces scope prioritization decisions when capacities nearing threshold
• Enables optimization of activities causing delays
• Determines batch sizes that maximize flow efficiency

Further, average cycle time and variability metrics provide the necessary data points for release forecasting and risk management.

Reducing Work-in-Progress Increases Predictability

Looking deeper into what impacts development flow, the amount of work-in-progress (WIP) is a key factor. The more feature requests, user stories, defects and tasks in flight simultaneously:

• The greater number of context switches for developers causing friction
• More multiple branching leading to integration issues
• Greater total cycle time from higher queue length
• Increased unpredictability due to variability stacking

Applying WIP limits smooths workflow, enables focus, reduces waste and enhances predictability through stabilizing the development process.

Smaller Batches Enable Greater Agility

Relatedly, batch size is another key work item attribute affecting development flow efficiency. Just as manufacturing plants realize benefits from smaller lot sizes:

• Small software batch sizes minimize lead time
• Higher test coverage ability when components not intertwined
• Reduces potential waste when adaptation needed
• Provides more feedback loops to engage customers

Breaking down requirement batches beyond user stories to singular feature elements yields additional agility benefits.

Prioritizing Value Over Estimates

Leveraging these queuing models enables planning new projects and product roadmaps without prescribed estimates. Flow metrics provide the necessary inputs for resource allocation and scheduling.

Importantly, prioritization can then focus solely on delivering maximum customer value. With development batches scoped to capability increments rather than predetermined effort targets:

• Flexibility retained to include emerging needs
• Avoids overproduction beyond Minimum Viable Product
• Capability aligns closer to current customer problems

The result is software products getting to market faster, with greater alignment to users and less waste.

Time Estimates Are Often Meaningless Guesses

Deming, a pioneer in modern quality thinking, popularized the phrase: “Your guesses are as good as mine and mine are no good.” This very much applies to the accuracy of task estimates for software development activities.

Innumerable studies have shown that developers are consistently and significantly over-optimistic in their time predictions. While very wide ranges are given to account for uncertainty, the estimates anchor around an optimistic minimum duration.

This is unsurprising given psychological research showing systematic human cognitive biases make us universally poor at estimating software engineering work:

• Anchoring and adjustment
• Optimism and wishful thinking
• Overconfidence
• Loss aversion

Even at an aggregate level, techniques such as Program Evaluation and Review Technique (PERT) promise estimate accuracy they are unable to deliver due to distribution fallacies.

Embrace Uncertainty as Part of Software Development

Rather than expend effort on guesswork with little value, it is better to embrace the inherent uncertainty in bringing new software products to light. Being transparent about the approximate nature of roadmaps reduces wasteful churn driven by target dates not grounded in reality.

Build contingency for the unknowns directly into development flow metrics such as WIP limits and queue policies. Scope work in small batches with flexibility to change course as new learnings arise. Move focus from output targets to business value delivery and foster a culture of collective code ownership for the outcomes.

While the temptation for certainty contained in a detailed project plan is comforting, it is rarely the most productive path. As Helmuth von Moltke advised: “No plan survives contact with the enemy”. Your enemy is complexity, embrace it intelligently.