Back in the old job (prior to acquisition) we had a very effective process for estimating the next release date of our core product. Our process was agile (for want of a better word), but with a few twists:
- no access to the customer (instead our Product Manager acted as the customer in terms of getting feedback on new features)
- the product release date was a hard deadline, so once we said the next release would ship on August 12′th for example, it had to ship on August 12′th (and it was then ‘promised’ to customers on that date, a dreadful practice but there you go..)
It took us years to years of refinement/trial and error, but we had it nailed fairly well in the end. Here’s roughly how it worked:
- the next release was to take roughly X months (some took 6, some too 12)
- Product Management gave us their wish list, and we in engineering also provided our own wish list of refactorings
- we did rough ‘finger in the air’ guesses about how long each would take
- we then worked with Product Management to cut the list down to something that could be roughly delivered in that time frame
- we then went off and worked closely with Product Management to define the requirements for each feature (and yes we used our own tool to do this!)
- we then did high level design, resulting in a ‘tech note’ document for each key feature (a combination of design notes/sequence diagrams/etc)
- then each developer went off and wrote out a big task list for each feature and estimated time for each task. Task time was estimated in hours, not days, as if you can’t break it down into hours then the task hasn’t been thought out fully and needs to be refined. The developer would also give a ‘Confidence’ indication of how confident they were of that estimate. For example, a straightforward task that would take a hour would be ‘100%’ confident, yet some tasks might depend on some core changes deep in the bowls of our code that the developer was not sure of might be flagged at ‘70%’. (Anything below 70% was an indication that more design work needed to be done!)
- after the detailed estimates were gathered, there was usually another minor round of feature culling with Product Management if the detailed estimates were coming in larger than the original ‘finger in the air’ estimates.
- the detailed estimates were all merged into one master project plan. Each developer would update this plan then on a weekly basis, putting in actual time and an updated estimate for how much more work was left on the tasks they were working on.
The benefit of doing this is you get a very accurate indication of whether your delivery is on target or not on a week by week basis, and any feature that was lagging was flagged early. There were other aspects to the process such as QA/bugfixing/etc which I won’t go into here, but from a Project Management point of view this spreadsheet was king.
Since I left the old job, I created a similar spreadsheet template which you can download here, I use it myself now for managing outsourced work in our new venture, Tax123.ie. If you have any questions on how best to use it, you can contact me.
Note: Joel has a similar mechanism which is now built into their tool which he calls ‘Evidence Based Scheduling’. It looks a bit more complicated than our little spreadsheet, but its nice to know that there’s a dedicated tool out there for doing this kind of project estimates – that would of been handy back in 2001! 
