Rethinking Software Estimation: From Outputs to Outcomes

Estimation, or more accurately guesstimation, is a backbone of traditional project delivery. From executives seeking budget approval to development teams planning their sprints, we constantly make predictions about time, effort, and cost. It's easy to understand why - businesses need to forecast ROI, allocate resources, and plan delivery timelines. Without some form of estimation, how can we make informed decisions about where to invest our limited resources?

Yet, despite its ubiquity, our current approach to estimation often creates more problems than it solves. Let's explore why our traditional estimation methods fall short and how we can achieve the same goals with a different approach.

The Fundamental Problems

The Cone of Uncertainty

In software, we never build the same thing twice. Even with detailed requirements, there are a lot of assumptions and potential points of misinterpretation. This means that we are making critical decisions at the start of a project with only a fraction of the information we need.

The Planning Fallacy

When it comes to forecasting, people are overly optimistic and systematically underestimate complexity, even when they have experience with similar work. We tend to remember the best-case scenarios and often discount past challenges.

Contingency Padding

To counteract the overly optimistic estimates from the points above, teams add large contingencies to protect themselves. A task that might take three days gets bumped to five days.

If we’re lucky, our counter-measures balance against our optimistic bias, allowing us to deliver on time. But more often than not, we end up with a project that is late, over budget, and under-delivered.

Burnout

Burnout isn’t caused solely by stress; it arises from situations where individuals feel they lack control over the outcome. As a project starts along a death march, the stress of missed deadlines and budget overruns can be overwhelming.

Shifting the Paradigm: From Projects to Products

I’ve lost count of the number of “Lessons Learned” sessions that I’ve been involved in. As an industry we’ve been learning lessons for over four decades and we still seem to be poor at estimating. According to the Standish Group’s 2020 Chaos Report, 19% of projects are cancelled and 50% are Challenged (over-time and over-budget).

The reason why we’re so bad at estimation is because we’re stying to put structure on an unstructured problem. It is the same as trying to pick lottery numbers and then running a lesson learned session because our method failed. Software development is design. It requires creativity, problem-solving, and collaboration. It’s not a production line where we can predict outputs based on inputs.

Businesses ultimately care about the impact of software - the increase in revenue, reduction in costs or gain in market share. But these metrics lag behind the release of new products and features so they are not good metrics to use to validate if teams are working effectively. In the past, factory operators would use in clock-in and clock-out metrics to determine how hard people were working. In software, effort is not a good indicator of impact either though, so we adopted metrics around how efficiently we can create the features (time and cost).

Unfortunately 90% of features fail to deliver the expected business value. So even if we deliver on-time and on-budget there is not a direct correlation to the impacts that the business is looking to achieve. Because of this many organisations are moving form output to outcome metrics. Outcome metrics track the usage patterns for the features we are developing with the assumption being that if people actually use our features then customer satisfaction and revenues will increase.

If teams are to be accountable for how well customers enjoy the products they are building, this creates a problem for how work is allocated. We can no longer treat development teams as delivery teams, building whatever requirements are given to them. The development team needs to take ownership of the idea as well as the delivery. Effectively, we shift from funding outputs (projects) to funding outcomes (products). This is a complex, but worthwhile, shift in how teams are structured and operate.

Creating Effective Review Mechanisms

While estimation is useful for upfront approval of what teams should work on, it is also a useful governance mechanism - are we on track against our upfront estimated timeline? If we fund outcomes instead of outputs we lose this governance mechanism.

Instead, we can implement weekly business reviews that examine real product and business metrics. These sessions should answer questions like:

• How are users engaging with our latest features?

• What's the impact on our key business metrics?

• What market feedback are we receiving?

• Are we moving toward our desired outcomes?

This approach ensures the focus remains on delivering value, rather than merely meeting estimates.

Practical Planning Approaches

Another benefit of estimation, is related to design. During the Design phase of a Waterfall project, or Sprint Planning, we are forced to think through how we will build the solution. This is a valuable exercise that helps us identify risks and unknowns.

While the Waterfall Big Design Up Front (BDUF) approach has significant issues, the iterative sprint planning approach offers considerable value. In sprint planning, the team estimates the effort required to complete each task either in time or story points. The real benefit is the discussion where the team members share their understanding of the problem and solution.

In order to do a high quality planning session though, each person is breaking down the solution into its component tasks and then estimating the effort of those tasks. The discussion surfaces where people are underestimating the complexity of particular tasks, or leaving out some tasks altogether.

But why are we asking multiple people to decompose a story into tasks in their heads and then making them wait a few days or weeks before they can start working on it, by which time they'll have forgotten the details of the discussion?

Instead, when a story is prioritised, the team should immediately break it down into tasks together. This allows everyone to have a shared understanding of the problem and solution, and the "design" is ready to be implemented.

Managing Stakeholder Expectations

Even when you have empowered teams, there is often a request from stakeholders to know when something will be delivered. Marketing, for example, may need to align their campaigns with the release of a new feature.

A team that I worked on had a rule that a task should not be longer than one day. The team were following Trunk Based Development, and they didn’t want a branch living for longer than a day. Since each task was a maximum of 1 day they would just count the number of tasks if anyone asked how long it would take to deliver the full story. Most stories were shorter than one day, so this simple rubric ensured they had some contingency in case of unforeseen issues.

Conclusion

Traditional estimation methods are inaccurate, give management a false sense of predictability and lead to high stress situations for the teams. By shifting focus to outcomes, adopting product funding, and breaking stories into manageable, day-sized tasks, teams can plan more effectively and deliver higher-value software.

The next time you're asked for an estimate, try shifting the conversation. Instead of debating how long something will take, discuss what outcomes you're trying to achieve and how you'll measure success. You might find that the best estimate is no estimate at all.