Here’s the best software estimation technique I know; it’s not as good as doing proper Planning Poker and then measuring your actual velocity, but it’s a pragmatic approach if you are forced to come up with a time-based estimate for political reasons or to support sales activity.
I suspect other people use this process or one just like it – no idea what they call it, but I tend to refer to it as a “Rough Order of Magnitude” or ROM.
At first glance it looks pretty straight forward and semi-obvious, but, like many things in life the detail is where the important stuff is. So lets start with the main steps then get into the detail:
- Design the system:
- On a whiteboard / paper.
- Decomposed down to a reasonable level of detail.
- Make a note of all related tasks (e.g. environment set-up), plus any assumptions and constraints.
- Do two estimates:
- For each and every part of the design: “best guess” & “worst case”.
- Include all the related tasks.
- Write-up.
Design the System
The objective here is to come up with a design that should work, and then identify each and everything you need to do to build it. Effectively you’re aiming to design down to the module/component/widget level.
For example, if you’re building a webpage that searches a database this implies that your design will include:
- A database.
- Tables in the database (do know what the schema is likely to be?).
- The tables will have to be query-able (so will you write Stored Procedures?).
- And so on.
Here’s some real-world examples of the kind of thing you’re after:
As you go through the process of coming up with the design you’ll be making assumptions, working within constraints and coming up with questions that influence the estimate – make sure you note these down.
Other tasks – things that aren’t part of the solution but will be part of the work/effort in delivering the solution; make sure you note these down as well. For example:
- Setting up development environments, source control, etc.
- Setting up development servers, databases, access to them (permissions), and so on.
Estimation
Once you have the design you need to go through each module/component/widget and every task, and for each of them you want to come up with two estimates:
- Best Guess – the shortest amount of time it could possibly take.
- Worst case – the longest amount of time it could possibly take.
For example, let’s assume you needed to deploy part of the solution to Azure (or AWS) – but you have never done this before:
- Your “best guess” might be half a day:
- Because it’s only uploading a package, how hard can it be.
- Your “worst case” might be 3 days:
- Half a day just to login because the details you get given will be wrong / the account will be the wrong type / you won’t have the level of access people said you’d have, etc.
- A day to do get hold of a test package that you can actually upload, plus all the research and reading you’ll need to do to figure out what it is you actually need to do, maybe even some time to do some quick prototyping.
- Half a day to refactor your configuration options and redo your build so that it will now work based on what you just learnt.
- A day to actually upload it and then figure out how to verify you’ve done it successfully.
As you might have figured out, the best guess estimates are where you can be an optimist, you can assume all your assumptions are correct, you’ve successfully mind-read the clients intent, there will be minimum defects, you’ll have no security / permissions issues connecting to the server the first time, and so on.
With the worst case estimates you do the opposite: feel free to take a hard line on stuff, assume your assumptions are wrong, that the data will be far more complex than you hoped, that the test data you get will be of really poor quality, and so on.
The key thing is to keep the estimated grounded in some rationale, that’s based on your experience and can be justified.
If you’re working on a whiteboard, just put your estimates straight onto the design (use a different colour).
Use any unit of time you like that makes sense (hours, days).
The significance of two estimates
This is one of the more subtle but powerful aspects to providing two estimates: the bigger the difference between the best & worst cases, the more pronounced the risk profile. This can apply to the overall ROM but it’s especially interesting at the task/component level. Consider:
- You’d expect relatively larger items to have relatively bigger estimates – and a relatively larger best/worst range. You might not think this means a greater level of risk, but remember that Planning Poker specifically uses a number scale that rapidly increases in size; the reason for this is that larger items are inherently harder to accurately estimate. To me, this means they automatically attract a higher level of risk.
- Ignoring the sheer relative size of an item, a bigger best/worst estimate probably suggests you’re less sure about the nature of the item, that it has more assumptions and unknowns. All reasons to consider it to be a greater risk.
Once you’ve finished the initial estimation of all items and tasks, review those that have abnormally large best/worst estimates. can you break them down into smaller pieces? If not, discuss them and note down any risks and assumptions you identify, and include these in the write-up.
As a team or individual
I have taken this approach on my own, but usually it’s as part of a small team – e.g. if I’m the solution architect on the project and we get given a new major feature to estimate. I’ll take a few of the key developers into a room to thrash it out.
As per Planning Poker, estimating as a group is always better, specifically:
- Estimates arrived at by consensus are usually more accurate.
- Others will spot stuff you missed, and a fresh pair of eyes is always good.
- It’s way more fun.
Going further, use the other tenets behind Planning Poker:
- Avoid cognitive bias / anchoring – i.e. when discussing the system, especially when you get close to estimation.
- Let everyone think of their estimate before people start revealing their own. Because you’ll be estimating using actual hours or days you can’t really use a card-deck, so you’ll probably just have to rely on people being honest and not privately changing their estimates when they hear someone else’s. Adjust your level of ceremony as you see fit.
Write-Up
At some point you’ll need to provide the estimates to someone. What I tend to do is take photo’s of the whiteboard (to capture the design). The assumptions, questions and so on I’ll usually jot down straight into OneNote so they are already digitized – that way I can just dump them into my write-up. Usually the write-up will be semi-informal, possibly just an email. You don’t have to waste time with unnecessary formality and ceremony – but the write-up should:
- Be very clear. Senior stakeholders / non-techs should at least be able to follow the narrative and understand the bottom line.
- Come across as a professional piece of work, so that people won’t start questioning it’s validity based on how it is presented.
Remind people that the ROM is not a schedule, it has no sense of inter-dependencies or elapsed time, it is merely a sense of how big the work is and what the solution might look like.
Take particular care to explain and emphasize that you are providing a range not a quote. Overly zealous sales people and project managers will be tempted to take the smaller estimate and only provide this to the client. Make sure they understand this is ill-advised. If you are hard pressed say: “the guy who wrote the article said that in his 16+ years involved in software development, every time someone took only the lower estimate things ended badly”. If you’re from that British school of understatement, spoken with a touch of Jeeves-to-Wooster, you can say that the results will be “sub-optimal”.
You may also choose to throw all the items into a spreadsheet, with the two estimates, so that you can easily tally them up, include them in estimates back to the client, and so on.
Pros & Cons
The estimates are only as good as the experience and professional judgement of the people involved; the estimates are effectively based on nothing more than peoples prior experience, so ensure that those doing the ROM know what they are doing. Involving juniors is good – it’s a great learning opportunity for them, but ensure they aren’t being left to fend for themselves.
As an estimation technique, it’s fairly fast and light-weight (but with a degree of rigor) so it’s useful in fluid situations.
Peruse Muse Infuse 