Asking for estimations of when a project might be complete feels grubby. It shouldn‘t have to, but no one likes it. Heck, when someone asks me for estimations, I know it could be useful but it still feels…off.
My approach is to explain how estimation is a useful exercise and how the estimates will be used. This makes it feel less grubby, and there’s other little rules that help prevent estimation from being misused.
Here’s what I’ve learned so far about estimating software projects. This is a living list that I’ll revisit and add to over time, so let me know if there’s anything I’ve missed or got wrong.
Rules for estimating software projects
The first rule of estimation is that accurate estimation is an oxymoron. Think in 2-week blocks, not days. Don‘t get in the weeds working out how many hours something will take. Use a broad brush.
The second rule is that the process can be more valuable than the output (like roadmapping). Figuring out the stages of a project and the work we need to do is more enlightening than knowing how long it could take, as it allows you to identify essential work you might not have considered. Good communication is more important than good estimation.
The third rule is explain how the estimation will be used. It could be that you need to plan releases, or make sure something‘s ready for/before a policy/legislation/regulation deadline, or align with another team‘s work, or work out how much of a bottleneck we‘ll have because we don‘t have enough of X role. You never need to know when something will be done for knowing‘s sake, so don‘t hide it from your team-mates. Be honest.
The fourth rule is that there are always undiscovered tasks. Until you‘ve uncovered all the unknowns, scoped a project (decided what to do now and what to do in later iterations) and made all the big decisions, you‘ll never know how much work there truly is to do. Which includes beta stages where you‘re collecting feedback – you don‘t know what‘s gonna come up. Timeboxing is better than estimation for discovery and alpha, but once you‘re at the beta building stage, that‘s when estimations are useful.
The fifth rule is revisit your estimations regularly. Things change, all the time (including your mood). It‘s also motivating to tick things off and mark them as complete, to step back and see progress made on a big project.
The sixth and final rule: never use estimates against people. There are too many external factors that negatively impact our productivity. If something took longer than we thought it might and it‘s a problem, dig into why. Your processes and organisation are probably more to blame than the people doing the work.
Got comments? Contact me, let’s talk.
A lot of my focus this week was spent on looking into Direct Debit.
Here's how I frame what we've achieved so far, what's left to do and what's next with product teams at GOV.UK.
How it helped not only with productivity and quality, and how it also contributed to strengthening our culture.