A raw estimate of the time required to deliver is one the frequent questions asked by the customer. It is a question that makes an Agile team uncomfortable. On one hand, estimating an entire product functionality without actually starting work is ridden with flaws, however in many circumstances, it is a practical question which teams cannot ignore.
Jarrod Roberson mentioned that one should never estimate a complete project because it is completely against the philosophy of Agile. The best, which can be done is that the team should set a date depending on the cost, other constraints and the product owner(s) should decide on what needs to be done by that date. Pascal Thivent added that any upfront estimations would result in a fixed scope which is the opposite of Agile. Another extreme suggested was that Agile teams should never get into projects which involve upfront estimation.
However, does this work in the real world?
More often than not, Agile teams would bump into a situation where the client would need a raw estimate to make various decisions. Hugo Palma suggested,
I think every client wants to have have at least an estimate of how much the implementation of a given number of feature will cost him. I don't agree with people that say that if your using agile than you can't do this. Agile can be adapted to the real world where clients want to know how much money they're gonna spend on a project, or at least have a rough idea.
Mike Cohn mentioned that he regularly gets questions around estimating hours required to deliver a product. His first recommendation is to put off the analysis until there is adequate historical data or at least a few commitment driven sprint planning meetings have been done. However, there are situations which demand a rough estimation. For those, Mike suggested a technique of working with a sample set of the backlog. He suggested finding an average number of hours for stories of each size.
If we averaged the 1-point stories on their own we might find that they were 3.2 hours per point, and the 2-point stories that were broken into tasks were 4.3 hours per point, and the 3-point stories were 4.1 hours, and so on.
We can then multiply that average number of hours by the number of stories on the product backlog of each size.
Mike cautioned that this technique would inherit all the shortcomings that would have been introduced during task identification and estimation step. Rob Bowley commented that the sample backlog technique would not work as software development is unpredictable and techniques like this end up under-estimating the amount of work which needs to be done.
There is no justification for trying to do something like this. It will invariably end up hugely under-estimating the amount of work and considering the sums of money involved in software development, either do real financial harm to an organization or wreck someone’s career.
Matteo Vaccari mentioned that though estimation with a sample backlog might help with some numbers however, there would continue to be multiple unknowns like team maturity, history of working together, definition of done etc. which would eventually make this estimate less useful.
Another option in such situations could be to do Scope Limbering as suggested by Martin Fowler. The idea is to start with a fixed scope contract and gradually educate the client on merits of Agile and help them overcome the FixedScopeMirage. Rob Thomsett also suggested a game of double and add some which is close to what Martin described.
Thus, it seems that none of the techniques are complete in the real sense. Each of them suffer with some element of subjectivity and have their own pitfalls. However, their application to situations which demand a rough estimate might be helpful to the stakeholders to make relatively better informed decisions.