Software estimation is notoriously difficult.
Developers loathe estimating because it puts them in a losing situation.
If they underestimate a project, they risk an unhappy client or loss of profit. However, if they overestimate a project or add a bunch of ‘safety padding’ to the schedule, they run the risk of scaring off the client due to budget/schedule concerns. Thus, the hapless developer who’s been tasked with creating a budget and schedule has virtually no chance of satisfying all the stakeholders.
The most common way to approach a software estimation is to to break the tasks down into smaller, easy-to-estimate pieces then estimate each of those individually. Once all of the smaller estimations are done, they are input into a large, unwieldy spreadsheet where the grand total emerges.
The idea is that smaller tasks are easy to estimate and should yield more accurate results. But, It just doesn’t work. Estimating this way simply makes complex projects even more complex and results in a poor estimation that looks fancy.
Leveraging Our Intuition
As a 30-year veteran of software development, I’ve come to believe that an experienced developer who isn’t burdened with the fear of being a scapegoat, can provide a software estimation off the top of his head that are usually just as good as a spreadsheet that took 40 hours to prepare.
Don’t believe it? Think about this: How many times have you seen a project deviate dramatically from the original estimate? And, how many of those times did you have a hunch from the very beginning that the estimate was wrong? That hunch was probably the result of many years of experience combined with a very powerful human brain – that is usually more insightful than an unmotivated developer staring at a spreadsheet for hours and hours.
That’s your developer’s intuition and it can be very powerful. Obviously, I’m not recommending that you begin estimating large projects based on a hunch. However, I’m certain that if you can invoke a bit of your intuition and stop relying on the spreadsheets so much, you’ll be much more successful.
Enter The Hotseat
The estimation hotseat is an exercise that encourages developers to leverage their experience and intuition. It allows developers to start trusting their instincts a bit more when it comes to software estimation.
The exercise simply asks developers to provide a realistic estimation for a software development challenge without doing any analysis whatsoever.
It works like this:
First, all estimations must be in the simple format below to make the exercise work:
x developers for y weeks
For example, a software application estimate could be: 3 developers for 12 weeks.
This simple format provides an easy and effective way to provide high-level estimations without getting bogged down the many moving parts that make up a software project. Of course, we all know that on a big project, developers come and go based on the state of the project. This makes it hard to simplify things into such a terse statement. But hey, that’s the point – we’re going to practice looking at things from a high level, and getting pretty close without sweating the details.
In other words, the format above doesn’t allow for any details, any nuance or any other information. It just forces developers to ignore all of the minutia and trust their intuition.
Developers typically take turns being in the hotseat. Each developer will be given a very short description of a software project and then their job is to estimate the job, in the above format, right away, with almost no information, and without asking any questions.
They simply have to think about it for moment, and then answer. A few seconds to think is no problem, but 30 seconds is too much!
So, a typical example would be:
The project is: ‘Port Minecraft to Oculus Rift’
And the answer might be something like:
30 developers for 1 year…
What’s the Point?
The point is not to learn to estimate projects in 10 seconds. It’s to show developers that their intuition is probably not far off the mark. As developers get comfortable with the exercise, they begin to realize that a from-the-hip estimation isn’t such a useless thing. Maybe they shouldn’t rely on those spreadsheets so much after all.
It also lets developers try their hand at estimating projects without the pressure of being right or disappointing anyone. This can be a rare treat for a developer who has always has to play defense when it come to estimations.
Empowering developers to be confident when estimating has serious value because most estimations suck and bad estimations are one of the top reasons projects go off the rails. Confident developers don’t hide behind a bunch of arbitrary numbers in a spreadsheet – they produce useful, insightful, and in many cases, accurate estimations with much less effort.
How Does This Apply To ‘Real’ Estimating?
It’s simple, really. We simply encourage developers to break down projects as much as they need to to get their head around things, but not anymore than that. Developers are continuiously encourage to use their intuition to ensure the software estimation feels right.
After the exercise, I always remind developers that instant estimations are fun, but if we were to take an hour or two and really dig into some high-level details, we could probably make an estimation that is more accurate than the detailed mathematical type in much less time.
Most developers agree.
Here’s a few minutes of the estimation hotseat exercise in action:
A few small clarifications and tips:
When we talk about developers, we can define that broadly to include DBA’s, QA people, even project managers, and other roles that are part of a core software team but may not actually write code.
When we describe completion time for a software project, we are talking about a complete application ready for release. It’s true that most projects require work after the first release, but we’re not talking about that here.
Participants can change their answer! You have to answer right away, but if you do 30 seconds of thinking out loud, that’s fine.
Ready to improve your estimation process? Try this fun exercise! Your developers and your clients will thank you for it! And, be sure to let us know how it went.
Dave Hecker
Latest posts by Dave Hecker (see all)
- Empowering Developers: The Software Estimation Hotseat - April 18, 2017
- Impressions from Lviv IT Arena 2016 - October 11, 2016
- Contracts with Russian Teams: Interview with Gene Taschkinov - September 30, 2016