Software Estimation on a Product Team: Part 2

Paul Sobocinski

Director of Engineering, Practice

engineer working on laptop

Four Reasons to Estimate

In my previous article, I covered three principles that help ensure a product team uses software estimation effectively: 

  1. Estimation Value: “We understand the value of estimates to us.”
  2. Estimation Autonomy: “We decide on how we estimate.”
  3. Estimation Ownership: “We all own the estimates.” 

Each of the three principles supports the other two. A team that skips over the estimation value principle subsequently fails to agree on the software estimation process, refuses to take responsibility for it, and may ultimately abandon the practice altogether.

At the heart of estimation value are the reasons product teams estimate software development work. In this article, I discuss the most common ones.

2 female engineers looking through code on laptop

1. Deciding what to build next

The most common question we seek to answer through software estimation tends to be:

“How long will it take to build?”

While this may often seem like the only question that matters, it’s not the only one that software estimation can help answer. When it comes to deciding what to build, or more generally what software changes to implement, here are a few more to consider:

  • How much system complexity are we adding?
  • What are we giving up if we choose to build this?
  • What is the regression risk of making this change?
  • How will building this affect our feature sustainability?

Depending on the approach, software estimation can shed light on all of the above. Furthermore, all of these help inform the team on the impact of a potential addition or change to software. Ultimately, these can help a product team decide what to build next, possibly even without answering how long it will take to build.

male employee working at computer

2. Deciding what to commit to

An estimate is an educated guess, which by its nature, is expected to have some degree of inaccuracy. A commitment, on the other hand, is an intention to ensure an outcome. 

Too often in software, the terms “estimate” and “commitment” are muddled. For example, a Software Engineer estimates the time they need on a feature, and then subsequently commits to completing it within that time.

This doesn’t mean that software estimation shouldn’t be used to inform commitments. If a team has historical data on estimate accuracy and precision, the team may agree to adding a buffer amount to the estimate so as to agree on a commitment. Setting a sprint goal is another example of team-based commitment setting, which is also often (though not necessarily) influenced by software estimation.

Therefore, as long as the terms “estimate” and “commitment” are not confused, then it’s completely reasonable to use the former to inform the latter.

male employee in front of whiteboard covered in wireframe prototyping

3. Planning sprints

The “sprint” is a cornerstone of the Scrum Agile methodology, which is the predominant one in the industry today — over half of product teams work in sprints. For a team to work effectively in sprints, it must effectively allocate the right quantity of work for the sprint. In turn, this means sizing and estimating the work at an adequate precision so that enough of it is completed to achieve the sprint goal.

This is one of the most challenging aspects of working in sprints. The value of working this way is the ability to deliver business value through meaningful changes to software behaviour that are deliverable to the end user at the end of every sprint (or sooner). Thus, if sprint work can be planned effectively, so can business value delivery.

Planning sprint work effectively doesn’t mean that the team has achieved the level of software estimation accuracy such that all work is completed precisely on the last day of the sprint. On the contrary, for teams that work effectively in sprints, it’s common for scheduled sprint work to complete a few days before the sprint ends. Conversely, some sprints may have scheduled sprint work carry over into the next sprint.

As mentioned earlier, there is one overriding factor that matters when it comes to software estimation for teams working in sprints: the software estimates only need to be precise enough so that the sprint goal is achieved consistently, sprint after sprint.

4. Planning for the long term

Use of software estimation for longer term planning, including roadmaps and work items (such as Epics) is often unreliable due to the size, complexity, and uncertainty of the work involved. Breaking down these work items into smaller stories for the purposes of estimation is also discouraged, as it can lead to constraining detail embedded in the work items’ requirements. This subsequently prevents changes to the plan when critical information (on the product or technology domain) is uncovered during implementation.

Therefore, software estimation in more long-term product planning should be used cautiously, and not as the primary driver of the plan. To put it another way, if the long-term success of a product hinges on a high degree of software estimation accuracy, the underlying business strategy should be reconsidered.

Having said that, in the context of the principle of Estimation Value, a team may find that long-term product planning is a viable and valuable reason for software estimation.

Closing Thoughts

We covered some common reasons for product teams to estimate software. Additional reasons for software estimation arise when other perspectives are considered. The ones I described here however, are especially relevant for product teams who are establishing a principled software estimation practice.

Part 1 of this series covered three principles that can help product teams estimate more effectively. Part 3 of this series will cover specific approaches and techniques that product teams can experiment with, tweak, and add to their toolbox as they continue to hone their estimation practice.

Related Posts