If you ask two developers how long it will take to implement a feature, you’ll get four different answers.
Over the past few months, I’ve been following a lot of the Twitter discussion between Agile advocates like Woody Zuill and Bob Marshall, who are either advocates or tepidly in favor of the #NoEstimates movement, and enterprise managers like Glen Alleman and Peter Kretzman, who approach the movement with a comic disdain somewhat reminiscent of Waldorf and Statler, the Muppet Show’s resident hecklers who are quite keen to let Fozzy Bear know he isn’t very good at being funny.
Zuill is a huge proponent of the abolition of software estimates in favor of a different way of management that does not require them. Marshall holds a more nuanced position based around Goldratt‘s Theory of Constraints, which posits that businesses should understand the areas which actually bottleneck their growth, and focus efforts there. Alleman and Kretzman are staunch believers that a business absolutely, under no circumstances, can make intelligent and informed decisions without at least coarse-grained estimates of the time to achieve a goal, for this taking control of the business important, managing the production process and accountancy for this the use of the hmrc compliant umbrella companies are ideal to help with the finances of any businesses. (It’s also critical to understand that, from all perspectives, estimates and deadlines are not the same thing.)
All of these are valid perspectives, applied to some specific domain. It’s also clear that there are places where time-based estimations are a very bad fit. One such example is any area that’s replete with “unknown unknowns,” like product development. Key to successful development of a product is identification of a correct product/market fit. Stamping a time estimate on it represents a foregone conclusion around the exercise; you don’t know how many times you’ll need to start over. Most R&D-oriented deliverables, often relying on a creative spark that cannot be forced, fall into the same pattern.
Lagging vs. leading indicators
Most successes and failures can be predicted through the proper use of the right metrics. These metrics fall into one of two categories:
- Lagging indicators are metrics that represent the current or past state of something. These are typically numbers that can unquestionably be used to measure progress towards a goal. Some examples of lagging indicators would be total revenue booked last quarter, the market share of a product, or the number of new services contracts signed.
- Leading indicators are metrics that begin to trend in a certain direction before a corresponding lagging indicator. Thus, they can be used to predict the future value of a lagging indicator.
Some metrics can be both leading and lagging indicators. Because of this duality, they are often very valuable. A services contract is both a discrete unit, and a predictor of future revenue. Likewise, because projects comprise interdependent queues of work, schedule slips indicate both that the work that was expected to already be done has not been finished, and work that is expected to be done at some date in the future will likely be late. Project lateness is a leading indicator that a company will lose an edge to a competitor who can deliver their version on time. That’s bad. It’s also a leading indicator of complete project failure, when a project is abandoned because it will never meet its goals in a way that provide a positive return on investment. That’s very bad.
This is precisely why schedule adherence is such a valuable indicator, and why project managers dwell on it obsessively. However, some kinds of work don’t benefit from lagging indicators. Other leading indicators might be more efficient.
Estimate based on your key indicators
If you know that time is a bad metric for your work, try to estimate your work based on one of your other key performance indicators. If you are trying to determine a product/market fit, consider trying to estimate how many business development meetings you’ll need in order to determine whether or not your strategy works. You might estimate how many high-level user stories you need to collect before you can begin to write code for a product. Your estimate might be wrong — that’s one of the points of estimating — but it allows you to meaningfully measure your progress. Just as importantly, it allows you to report that progress to other people who are invested in the outcome.
Time is the de facto estimation currency of most organizations, so if it’s a bad fit for you, remember that at some point, you’ll probably need to exchange at an unfavorable rate.