Software Estimation on a Product Team
Part 1: Three Estimation Principles
The topic of software estimation tends to be an unavoidable one for product teams. It is often a source of contention, as every team member brings distinct experiences and opinions on the topic. While there is much disagreement, a common shared experience is that underestimation is more common than overestimation. This tends to create an undertone of cynicism towards software estimation.
This mindset towards software estimation underscores the importance of exploring the topic. When applied effectively, software estimation is a powerful tool that can help teams select, prioritize, and implement software changes optimally and reliably.
When teams fail to intentionally broach this often-uncomfortable topic, it’s discussed at inopportune times — while the team is stressed, under pressure, and in a reactive mindset. This leads to an outpouring of ‘whys’:
Why is this estimated at a “3”?
Why are we estimating this way?
Why does estimation take so much time?
Why do we even estimate in the first place?
Although these are important questions, they can feel distracting if they’re brought up while the team is focused on “doing the work.” This could mean delivering on a sprint goal, unblocking a WIP limit in a Kanban lane, or any modern Agile methodology adopted by the product team. Regardless of the methodology, the need for software estimation is unavoidable. Even #NoEstimate teams review the work and ensure that it is “right-sized” before it is worked on, which is arguably a form of estimation.
Having worn the hat of Team Lead for over a decade, I’ve observed, experimented with, and adopted various approaches and techniques for estimating work on a product team. As I began to write this article, however, I realized that any elaboration in that vein is premature without first reflecting on the principles behind effective software estimation.
In that regard, I share three principles that I have found helpful in fostering and maintaining a team’s shared understanding of the practice of software estimation.
Team Estimation Principles
I. Estimation Value
We understand the value of estimates to us
As with any process, it’s prudent to ask whether its value outweighs its cost.
And software estimation is costly. Teams spend time in meetings to debate and agree on estimates. Time may also be spent on a spike solution to gather the information needed for a reliable estimate. In addition to the time-cost, there is a mental load to estimates which can manifest in the team periodically reviewing work to check if it’s in line with its estimate.
You may be thinking: “I get it. Estimates are costly. But we need them. I know why, and my team knows why, too”.
Are you sure about that, though?
Without an open and recurring discussion, every team member may have radically different reasons for understanding why estimating software is important. This surfaces as a problem when the process around estimating software fails. When this happens, the team struggles to agree on how to improve, because the underlying reason for software estimation has not been established by the team.
Furthermore, having a reason may not be sufficient to justify the practice. This is because our reasons for estimating software should tell us why it’s valuable for us to spend time and effort on establishing estimates. Given that software estimation is costly, it’s important for the team to question whether the value outweighs the cost. Furthermore, as product teams are subject to frequent and rapid change, the question should be revisited periodically (during retrospectives, for example).
Here are some common reasons why product teams estimate software development work:
- Deciding what to build next
- Deciding what to commit to
- Planning sprints
- Planning for the long term
We will cover these reasons in further detail in an upcoming article. Providing that teams are sufficiently empowered to decide on the reasons for software estimation, these can be as diverse as the teams that own them. This closely ties into the next principle.
II. Estimation Autonomy
We decide on how we estimate
Now that we’ve established the importance of team alignment around the value of software estimation, let’s explore another principle that is just as critical: Estimation Autonomy.
Realizing the value of software estimation is highly dependent on the approaches and techniques that are applied. For example, the team may need to implement a spike solution as a means to assess the technical complexity of a software change; in other cases, this approach results in unnecessary overhead. Occasionally, a team may choose to timebox certain work items — this is especially common for exploratory work, such as investigating the root cause and reproducibility of a bug.
Considering such examples, it’s important that the team decides on the approaches and techniques for any given scenario. It doesn’t necessarily mean that every work item is approached in a distinct manner. For example, a team may decide to estimate all work items in fibonacci points so that sprint velocity is measurable over time and thus predictable for future sprints.
In this way, Estimation Autonomy supports Estimation Value, because the team is able to adapt its process quickly to ensure estimates stay valuable to the team. However, these two principles are not sufficient on their own for ensuring that the team uses software estimation effectively.
The third principle can be thought of as the “glue” which holds them together.
III. Estimation Ownership
We all own the estimates
The principles of Estimation Value and Estimation Autonomy assume that the team is solely and completely responsible for software estimation. Specifically, the team is responsible for its effective use.
While a team may acknowledge a responsibility towards software estimation, it can fail to give it sustained attention. This, in turn, can cause estimation value to erode. Here’s a scenario that depicts how this could play out:
- The team deems software estimation as a planning tool, so it’s given attention either just before or during team planning activities (such as sprint planning).
- The team rarely has time to revisit old estimates and assess their accuracy. Outside of team planning activities, software estimation is not discussed.
- Nonetheless, the team finds that estimates can and do play a role in influencing the work itself. If a work item is taking longer than estimated, some software developers feel pressure to finish it quickly.
- Some team members feel that underestimated work should not be rushed, but the team does not have the time to discuss what the best practice should be.
Estimation Ownership means a sense of ownership of both the process of estimation and the estimates themselves. This sense of ownership should persist beyond the team planning activities and carry through to the day-to-day implementation work. It means that the team feels that they own it both as a group and as individuals.
Embodying this principle means that the team is motivated to call out and resolve process gaps such as the one in the scenario described above. If overestimations happen too frequently and historical occurrences are not discussed, the team adapts its process to address these issues. If the team feels that these issues are not worth solving, then it may be time for the team to revisit its shared understanding of Estimation Value.
Closing Thoughts
Building software is hard. Estimating software is harder. Is it worth attempting software estimation in the first place? Oftentimes, yes. Should teams adopt the practice for reasons such as, “because other teams do it”, or “because we’ve always done it this way?” Probably not.
Software estimation can be a highly effective tool, but if a team fails to apply it diligently, it may not be worthwhile for the team to continue the practice. Alternatively, teams can take a principled approach to the contentious and costly endeavour of software estimation. In reality, the best approach is the one that delivers on every product builder’s main goal: to build better products.
