Single-point estimates are very often taken as promises, used as deadlines, create overhead, hides risk, becomes illusion of control.
Don’t use hours, f.ex do range-based estimates, think pair work, only focus on remaining work, adjust regularly.
F.ex when doing continuous forecasting, we need regularly updated capacity and remaining scope.
A few things to think about:
- knowledge work, creative work, innovation is invisible, unpredictable to an extent, non-repetitive
- we like to automate the repetitive, predictable…
- the human brain have a lot of systematic biases
- re uncertainty – average deviations from estimates accumulate upwards
- pair (and mob) programming results in higher quality
Estimates, especially single-point estimates made when starting an effort and not adjusted continuously:
- are very often taken as promises, used as deadlines
- create overhead, waste
- hides risk
- becomes illusion of control
What we really need:
- facilitate continuous discovery, planning, forecasting
- understand work
– common understanding of work, both within f.ex dev team and between business and software developers - early, real feedback
– break down to minimum viable work items - mitigate risk, make decisions
So, when f.ex doing range-based estimation for continuous forecasting; for each broken down work item:
- Don’t estimate hours – rather days
- Think code review, pair programming, etc, working in pairs at least – not “single developer days”
- Focus on remaining days continuously – don’t bother with “accounting” of spent time unless there’s a really good reason
- Estimate (guess) a realistic amount of work, and call it “optimistic“
- Guess a pessimistic amount
– and remember that uncertainty has a long tail upwards (there’s a limit for how much you can overestimate, but not for how much you can underestimate) and that our brains systematically work against us - Revisit estimates regularly, since you learn more about the work continuously – and only bother with remaining work