Recently I attended the Lean Kanban UK conference and was interested to hear peoples opinions on estimating.
Estimating vs. Forecasting
Dan Brown’s (@KanbanDan) session, ‘Forecasting delivery, with oranges’ (see his blog post). The essence of session was that estimating the cost is in itself an expensive business an can be avoided. If you capture the facts about your deliveries then you can use this for future forecasting. I also believe in this idea as you are now dealing with the facts of the delivery, something that is promoted through the use of Kanban. Sure this still presents the problem that a forecast is not a fact, and as much as you scream the word ‘forecast’ the customer may only ever interpret this as a promise. But at least this way you are not burning the teams time drawing up guesses about the cost. A quote from a client with agile growing pains related to concentrating on cost estimates, ‘we’ve spent all this time talking about the process (estimates), and nothing on the features’. In my experience of software development this is not unusual, and is one of the reasons agile approaches are abandoned.
Estimating cost vs. Estimating Value
The same argument can also be re-written as cost vs. value as highlighted by Allan Kelly (@allankellynet), ‘No Projects, Beyond Projects’. Estimating cost, i.e how long will this take, is the wrong angle to take, estimating the true reason for the development is where the focus should be. At a simple level this is about prioritising what is really required, similar to the approach of the ‘five whys’. This is at the heart of agile but is often lost in the process, we need to deliver value, not just working software.
Ignoring requests for Estimates
So if estimating is bad then why should we do it? We have seen that forecasting can be used, but since that is evidence based it is not always possible or deemed accurate to use. I talked to a number of attendees about this issue and one of the common themes was, ‘we ignore the request’. One technique was to literally ignore the request and just keep delivering until trust was established. Another was to ignore it for the first delivery and then substitute forecasting. I also asked this question to a very well known developer and author, who I’ll think I keep their name secret (ask me directly and I’ll say), that they would provide a completely fabricated Microsoft Project Gantt chart which is then thrown away once the trust in deliveries is established.
Small one off fixed-priced projects
When you are bidding for a small project where there are a number of unknowns, including the customer, then you are left with choosing between finger in the air gut feelings or attempting a forecast based on categorising the project against previous deliveries for other customers. Larry Maccherone (@LMaccherone ‘The impact of agile quantified‘) and Dimitar Bakardzhiev (@dimiterbak) (amongst other interesting points) both championed using statistics to aid in decision making. In terms of forecasting Monte Carlo Simulation (Intro with Excel, Dimitar’s SIP Monte Carlo & High Level Project Planning) looks to provide a relatively simple way to provide a worst-best forecast. However, has Dimitar pointed out it is best suited to when you can successfully match the project variables against previous statistics, including; solution type, technologies and team.
For me the conclusion is that estimating value is generally a bad idea. The ideal is to establish trust via deliveries, backed up with forecasting if necessary.