Estimates or “How to dig your own grave”
This is part of the series covering the PHP Nw 2011 conference. View the rest of the posts on this event here.
This was one of the best talks that I’d attended, despite not being about PHP, but about the problems with estimates and how to avoid them. Rowan wasn’t even shaken by the multitude of technical issues which delayed it, but I’m sure he’d factored in the risk of that happening.
The talk was split into two main parts, starting off with the possible mistakes, and then how to spot problems and resolve them. It’s certainly making a difference in the way that I now handle estimates (something I’ve always disliked doing). At the end of the day, it comes down to a few common sense rules for making estimates and managing risks and estimating appropriately.
Problem – The sales team creates estimates
This is something that everyone who’s ever worked in any sort of commercial environment can relate to, and it was most certainly true for me. I’m not sure if the sales team are just overly optimistic when quoting timescales and costs for a project, or if they think the only way to win the work is to massively underestimate, but it never works out.
The solution to this however is simple, let the person who will be doing the work, and has a much better idea of how long it will take, give the estimate.
Problem – Estimates from a single developer
Even when you give an “educated” estimate as a developer, it’s still easy to get it wrong, which is why you should ideally not get an estimate from just one developer. Ideally the estimates would be made independently and then an average would be taken (although any outliers would be investigated), but if that’s not possible, they should always be reviewed.
Now not everyone is fortunate enough to have other developers with which to review their estimates, but even with just the other tips, you’ll still improve your estimates.
Problem – Estimates from a detailed list of tasks
One of the common guidelines given when estimating for a large job is to break it down into smaller chunks and estimate each chunk. If this gives us more accurate estimates, logic would dictate that further breaking these down to very detailed tasks would yield even more accurate estimates, but unfortunately not.
If you get down to this level, your estimate is almost immediately void, as things always change, but you have misplaced confidence in your estimates as you think they’re accurate to the nearest 30 seconds. This also has the side effect of encouraging micromanagement, which no one wants!
Problem – Estimate in hours
Leading on from the above, estimating in hours not only encourages too much granularity but also doesn’t map to days conveniently (see next point). Think in terms of days, using an increment relative to the size of the project, but no smaller than a quarter of a day, up to a week at a time on larger projects.
Problem – Estimate work in 8 hour days
If you created a detailed list of tasks and durations as mentioned above and then divide the number of hours by 8 to get the duration of a project, you have a problem (or several):
1. Taking a 9-5 job, you have an 8 hour day, but take out an hour for lunch, and you’re left with 7 hours of “work” time
2. Of these 7 hours, you can’t work on a single task without any interruptions, breaks or context switches. Every time you switch task or get interrupted, you need to get up to speed again
A developer can expect to get about 6 hours of actual work done on a good day, and a lead developer just 4 hours.
Problem – Just estimating coding time
It’s far too easy to get caught up and just think about coding time, but unfortunately we need to deal with numerous other tasks including documentation (both internal API documentation and end user documentation), testing, deployment etc. On top of this, there will always be bugs and amends (no matter how perfect you think you are) as well as the overhead of running a team project (communication, management etc).
Problem – Waterfall estimates are next to useless
Although most projects involve some amount of boilerplate functionality which is easy to estimate, as you’ve done it a million times over, there’s still a lot you don’t know. With the Waterfall model, there is the “Cone of Uncertainty”. This means that at the start of the project, your estimates will likely be wildly inaccurate, and as you progress closer towards the end, the cone starts to close, and your estimates get more and more accurate. This has led to the growth of agile over the last few years, but unfortunately people using agile think they can’t estimate a whole project at the start.
Solution – The holy triangle
The holy triangle is based on 3 axis, where adjusting 2 affects the value of the third. The possible combinations are:
- Good, fast and expensive
- Good, cheap and slow
- Fast, cheap and bad
Although it is possible to have high quality and quickly, it will be expensive – Something most clients will fail to comprehend.
Solution – MoSCoW
This stands for Must, Should, Could, Won’t and help the client to understand that not all functionality is created equally. Unfortunately a client will initially think that everything is a must, so hopefully the following will clear up what’s a must versus a should, could or won’t:
- Must – Critical to the project, which would be a failure without it. The project could not launch without all the must features implemented
- Should – Most things that the client thinks is a must will actually fall into this category. Although you can launch without these, it’s best to do them if you can, as they will often help improve the usability or make it unique
- Could – These are the nice to have extras, but in no way, shape or form crucial to the project. If there’s enough resource left once all the must and should features are done, you can work on these
- Won’t – No, just say no to these features
So how does this help? Well, you’ll likely have just halved your workload as it turns out you don’t need all the bells and whistles the client thought they needed. It also helps to manage client expectations, because as long as you have all the musts implemented, you can still launch without the rest, reducing the risk of overrunning (for the initial release).
Mistake – Lose track of time
Unfortunately, we’re all terrible at tracking time for 2 main reasons:
1. We dislike anything that’s not actual coding, so time tracking is seen as a chore
2. If we’re switching between tasks regularly, the time tracking becomes very fragmented (although in this case, context changes are the bigger problem)
Despite this, it’s important to track time, so that you know where you are relative to your estimates and if they’re accurate. The sooner you can identify a problem, the better.
Mistake – Estimate bugs
By their very definition, it’s impossible to estimate how long it will take to fix a bug, as the exact cause is unknown. I’m sure we’ve all spent numerous hours, if not days, to find a trivial, one line fix. As you can’t estimate the duration of finding the cause of the bug, you need to have this buffer factored into the overall estimate.
Mistake – Not learning from mistakes
At the end of every project, we should review everything that went well, but more importantly, what didn’t go so well. If estimate were under, identify the cause so you won’t make the mistake again. If there was something that took considerable time that wasn’t factored in, make a note do you remember last time etc.