Software Estimation on a Product Team: Part 1
This was originally published on the Connected blog in 2020 by Paul Sobocinski . Connected was acquired by Thoughtworks in April 2022.?
In the world of product development, software estimation is an unavoidable topic for product teams and a powerful tool when applied diligently. Building software is hard. Estimating software is harder. Is it worth attempting software estimation in the first place??
In part one of this four-part series, Paul Sobocinski, Engineering Practice Director, explores three key principles that lay the foundation for effective software estimation. Dive into the value, autonomy and ownership of estimation now to discover how these principles serve as a powerful tool for building better products.
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’:
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:
领英推荐
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:
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.
The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.