I’ve been doing a lot of estimation and planning recently for a major release. I’ve gotten some information from the STAR EAST conference I went to and attended a few sessions, a book (Software Estimation: Demystifying the Black Art) that was recommended, and there is a local TISQA meeting tonight with someone I really respect talking about estimation, Shawn Bradshaw. The estimation that I’ve been doing so far is not overly complicated, I do use my judgment for some of it but there is plenty of historical data, calculations, and an attempt trying to take an objective view of it.
The biggest problems that I’m having currently is that I’m estimating based on something we haven’t looked at the majority of yet. New features ( some with requirement’s and others not so much), new OS version, new DB version , and a load of already existing issues that are scheduled to be fixed in this release. It helps that the book says that’s OK, that’s what an estimate is, at least a high level. It’s different than how I’ve traditionally thought about it in the past but it’s true, an estimate is not a prediction, or a schedule, or a commitment to meet a target, it’s just an estimate.
I also like the idea of not giving a number estimate “This project will take 6 months”, but rather giving a range “By my estimates it will take between 20 and 38 weeks to complete this project”. I don’t think that will go over well at all, some folks will reject the 38 week estimate out of hand and some will latch onto the 20 week one as the “number” that I’ve “committed” to. The best approach may be to give the percentage change that we’re going to hit their target “Looking at our historical data, We have a 30% chance of being done at the 20 week mark and a 90% change of being done at 38 weeks.”* Giving the estimate as a chart seems to be the way to go and I’m going to try that this time.
*These numbers are made up while I am writing this, just to be used for illustration.