Software Estimation on a Product Team: Part 2
September 15, 2020
Four Reasons to Estimate
In my previous article, I covered three principles that help ensure a product team uses software estimation effectively:
- Estimation Value: “We understand the value of estimates to us.”
- Estimation Autonomy: “We decide on how we estimate.”
- 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.
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.
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.
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.
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.
Thu Dec 1
Global Day of Coderetreat Toronto 2022
Earlier this month, we hosted Global Day of Coderetreat (GDCR) at our Toronto office. After a three-year hiatus, we wanted to re-awaken some of the community enthusiasm when we hosted the event for the first time back in 2019. This year we planned for a larger event which turned out to be a really good thing as we nearly doubled our attendance. And in case you were wodering, this is how we did it.
Tue Nov 29
Art of Controlled Burn in Engineering Management
The idea of a Controlled Burn is simple; create a small fire that you fully control. The assumption is that were you to do nothing, a much larger disaster would occur. In agile, no team likes disruptions; rather, everyone prefers to work like well-oiled machines. This begs the question - can we apply a strategy that looks very similar to firefighters and utilizes controlled disruptions rather than waiting for a full-blown disaster to occur?