Estimating Software Development: It’s Not About You
There are a lot of articles about software estimation techniques, from story points to hours to t-shirt sizes. What does a story point actually mean? Is it a measure of complexity, size, or time (one product manager that I worked with used to refer to them as “unicorn horns,” because he felt that they had no inherent meaning)? Should you use planning poker? What about having your boss estimate for you so that the engineers can just get on with their work? Have you ever sat in a planning meetings where they spent an hour or more to estimate a single feature story?
Driver For Estimates
All of these discussions miss the fundamental driver for estimates. That doesn’t mean that they aren’t useful in their context, but they ultimately boil down to a simple question:
What can be delivered in a given time period?
The question of who (e.g., a given team or a group of teams) and the specified time period (e.g., two-week iteration or a quarter or a year) can change based upon the type of estimate.
But, even this question misses the point (a little), because what the estimate is really about is setting expectations with stakeholders. Those stakeholders are primarily two sets of people: management and customers.
We sometimes call this predictability, but that word doesn’t actually work very well, since estimates should never be considered commitments. Hence, setting expectations works better than an exact prediction.
It’s Bigger Than a Team
Here’s a simple example view of estimation as it progresses from a micro-level to a macro-level:
- Each team estimates a set of stories (i.e., business value) that can be accomplished in the next iteration
- Stories are organized into groups (e.g., epics) that are estimated across quarters (and potentially, years)
- The business looks at these estimates and determines when major products (and product features) can be released
- The business can then prepare marketing and advertising for these products
As part of this example, the business can calculate the Net Present Value of the product to determine whether they should invest in the product (or product features) in the first place.
In other words, the estimation process is ultimately not about an individual developer or a team or a team of teams, but about a business setting expectations within themselves (via coordination across teams, organizations and divisions) and with their customers.
If It’s Not About You, Then Why Does It Matter How It’s Done
There are two side-effects to the process of estimating software development that are critical to an individual and a team that are separate and distinct from the business use identified above.
Given a relatively accurate estimate — that’s a big assumption, I know — an organization fundamentally doesn’t care how estimates are done as long as it can use those estimates to meet its business needs. That means that the approach and process used for estimating is really about these two side-effects:
- Improving the accuracy of estimates
- Understanding the problem and the solution
Let’s look at these two in a little more detail.
Improving the Accuracy of Estimates
Estimates can get better over time if they are reviewed and analyzed. This is an area that is typically ignored by individuals and teams because it’s not easy and little to no training is ever provided.
Regardless of the approach or type of estimate (whether complexity, size, or time), a specific estimate can be compared to the work performed (once it’s been delivered) and adjustments can be made. The appropriate estimation measure should take into account this review and analysis process — otherwise, it’s missing out on one of the primary means of improving accuracy.
Note that the analysis of an estimate is based upon what was delivered and the approach used for estimation in the first place. Teams should be able to identify methods for this review process (as this process is out-of-scope of this article).
Understanding the Problem and the Solution
It’s a mistake for a team to accept new work and start on it without understanding even the most basic questions about the problem to be solved and the basic approach to solving it. There are many examples of engineers who are surprised by what was required after delivering their solution. There are also many examples of engineers spending a lot of time trying to figure out how to deliver the solution because they didn’t think through it before they started the work.
By spending time up-front during the estimation process, engineers can ask appropriate questions about the problem domain and discuss basic solutions and approaches to delivering it — this is especially true if they are able to do this with their team. They can even break down the work into smaller pieces to help track their progress and ensure they don’t forget what they discussed up-front.
This “discovery” phase for the work helps to ensure that the estimate will be more accurate and also helps to ensure a more successful delivery.
Conclusion
Estimation, at its core, is about setting expectations for stakeholders. That’s why it’s fundamentally not about you (assuming you’re the estimator). Engineers may feel like they shouldn’t provide estimates, since it’s “going to be done when it’s done,” but by communicating expectations, those stakeholders can more successfully do their own work.
However, that doesn’t mean that engineers can’t get a lot of value out of estimating, since the more accurate their estimates, the better the outcomes for them and the business.
Additional Note: some may be disappointed that I didn’t include a “sense of urgency” as one of the outgrowths of estimation. This was purposely left out, as it has a tendency to be abused by management (and other stakeholders) to push engineering in such a way as to significantly reduce the quality of the product as well as the morale of the engineers.
