Software Estimates are a Two-Sided Relationship
Most software engineering features start with an effort estimate, either in terms of time, manpower, or story points. Much has been said about the provider of software estimates; how to give accurate estimates, how to gauge confidence level, and so on. However, this neglects to mention the other important party: the consumer of said estimates.
Typical estimate consumers are project managers, product managers, product owners, and engineering management. This group of people may not have the most context to size the effort required to complete a project, so they depend on the expertise of the estimate providers. Hence most estimate providers are the engineers who are going to work on the feature, or who have worked on similar features. Just as we expect the provider to be responsible and professional in giving the estimates, there are also expectations and responsibilities imposed on the consumer.
Responsibilities of an Estimate Consumer
The consumer should be an active participant in the discussion of the estimates.
Validate the assumptions and tradeoffs
“What exactly are we estimating?”
The estimate provider is bound to have assumptions and make tradeoffs in deriving the estimate (otherwise it won’t be just an “estimate”); and their responsibility is to make it clear. The estimate consumer has the duty to understand those assumptions and tradeoffs made and if not, probe further until everyone involved is on the same page. Otherwise, they risk accepting an estimate of something different from what they had in mind.
Internalise the confidence level
“How sure are we that this estimate will come true?”
All estimates come with uncertainty. It is the job of the estimate provider to determine how confident they are with the numbers, and it is the job of the consumer to internalise that confidence level. Ask questions if the certainty of the estimate is unclear. This can go both ways, are the estimates overly confident? Is it a 90% or a “back-of-the-napkin” estimate? How much could it vary?
Give the right people the right duration to do estimates
“Is this estimate given by the right people and with enough time?”
Estimating things requires context; I could estimate your next feature but that estimate wouldn’t be useful. The best estimate is usually given by the team who is going to work on it. Estimating also takes time; the quickest estimate is most likely the lowest in confidence level rendering it not very useful. The team will need time to dig through existing code and consider wider implications.
Avoid influencing estimate discussions
“Have we influenced the estimate in any way?”
It is very easy to add subconscious bias to estimates, for example by emphasizing that it is “make or break”, or by pushing for a “tighter” estimate. An estimate created in such an environment will be far less accurate and therefore far less likely to be close to reality. Present constraints objectively and avoid stakeholder pressure from affecting the estimates.
After an estimate is produced, the consumer should also be professional when using it.
Remember estimates are not set in stone
“How has the estimates changed since the project started?”
Estimates are just that — a forecast. They can change as the project progresses. They come with inherent uncertainty; reality could be simpler or more complex than estimated. They should never be used to commit deadlines right at the start of the project; it is incredibly irresponsible behaviour to make an unchangeable commitment using an early estimate. Be open for negotiation of scope and estimate changes.
Follow up estimates actively and escalate immediately
“How does the estimate look now?”
If the estimate is important, it is only responsible to be actively following it as it changes, just as it is expected for estimate providers to be actively updating it. Join discussions about re-estimates, keep up with conversations, and sound out immediately if the estimate varies beyond your comfort zone. It is very easy to become a passive consumer and assume that any updates will come knocking; but if an estimate is indeed important, its current state and the ongoing discussions should be on the radar.
Honour the conditions during the initial estimate
“Has the conditions changed from when we started?”
The initial estimate comes with assumptions, tradeoffs and is associated with a confidence level (“the conditions”). If there are drastic changes to estimates, it is useful to recall the initial conditions and whether they still apply. It is unprofessional to hold estimate providers to their initial estimates, if the initial expected conditions are drastically different from the current.
Estimates are a two-sided affair. It needs attention, effort, and professionalism from both parties. It requires responsibility on both sides for it to work.
Otherwise, the estimates may end up becoming a white elephant, or worse, being interpreted to mean more than just an effort forecast.
Other stories you may like
- Write fluent code in Kotlin
- Exploring Double Equality in Kotlin
- Use Java Nullability Annotations to facilitate conversion to Kotlin
I also write about the TryHackMe rooms (Pen Testing)!
