The #noestimates movement is a subject that has generated a fair amount of controversy in the software development community since its inception, including within the team here at Made.
Last week, my colleague Chris discussed several reasons why #noestimates is A Good Thing. In this article, I’ll be arguing why completely foregoing estimations in project delivery is a bad idea, and why there may be a compromise.
Within the world of Agile, estimations are part of a number of methodologies, particularly Scrum, with practitioners meeting at the beginning of each sprint to plan out and estimate the work to be done in that period. The meeting gives everyone a chance to raise concerns, ask questions and get a very high level overview of the work that needs doing.
Although we’ve been experimenting with #noestimates on some of our more recent projects, we’re still fans of practicing Scrum, and the following are four reasons why we feel those estimation sessions are important:
1: They’re Estimates, Not Exactimates
Estimates, by definition, are rough guesses, and are ultimately very likely to be off the mark. A piece of work may take longer than expected, and that’s fine. Trouble only sets in when developers get attached to estimates and treat them as absolute, immovable deadlines.
The onus is on you, the developer handling a given task, to communicate to your Scrum Master that you feel something is going to take either a lot more time to complete, or a lot less. Your Scrum Master then has the info he or she needs to make the best decision for the sprint at large, which will likely involve discussing the situation with the client, and then either reducing the scope of the sprint, or pulling more tasks in.
2: Chance Favours The Prepared Mind
It’s true that we estimate when we know least, but planning and preparation is an important process in any project, in all walks of life. By spending time estimating, with as much knowledge as we have at the time, we give ourselves the best possible plan for the sprint ahead as we discuss and discover the tasks that will likely need the most time spent on them.
This allows us to either prioritise those tasks within the parameters of the current sprint cycle or, if we know there are more pressing tasks to complete beforehand, push it to the next sprint in order to fill the current sprint with tasks we’re confident we complete.
3: Trust Issues
The #noestimates movement requires a massive amount of trust between you and your client, as you’re effectively removing the one thing that gives them a sense of how long the project will take, and how much it will cost them. For most clients, that’s a huge risk.
Without an estimate of how long it will take, how can they be confident that their project will come in at a reasonable cost? What grounds do they have to take you at your word that you’ll demo progress at regular intervals?
Existing, flexible clients with whom you’ve built a significant amount of trust may be willing to experiment with the idea, but you’ll struggle with asking a new client to throw money into the unknown.
4: Being Bad At Something Doesn’t Mean We Quit
Yes, people are typically bad at estimating, but with experience we learn to spot where pain points are likely to arise and adjust future estimates accordingly. We’ll still get it wrong from time to time, maybe even drastically so, but estimation remains an essential tool for figuring out a roadmap for the upcoming sprint.
Can’t We All Just Get Along?
As hotly contested as #estimates vs #noestimates is, a more level headed approach may be to only estimate when absolutely necessary. Mike Cohn, a prominent figure in the Agile community, put it best: “A team should estimate and plan only to the extent that further investment in estimating and planning will lead to different actions. If you will do the same thing even if you estimate or plan more, stop.”
About the Author
Software Engineer at Made Tech
