I met many readers there, and was pleased to discover that the humour in this column is well received. I was also pleased to discover that a lot of you want to know more about agile processes, and extreme programming in particular. Now, if you’ll all take the next small step and just try it ….
Steve McConnell, the third most influential person in software engineering anywhere, was there, talking about software estimation and his new book on the subject, which is destined to become another best-seller.
He recommends splitting requirements into very small manageable chunks, and estimating each of those independently. This technique is based on the statistical law of large numbers, which states that a sum of errors is less than the error of a sum.
What does that mean? If you break your requirements down into 100 chunks, and estimate each of those with a 50% margin of error, when you add them all up it is likely that those errors will cancel each other out – some will be positive, some negative. This leads to an estimate that is, overall, accurate. However, if you consider the requirements as one big chunk, and provide an estimate, again with a 50% margin of error, then you have a high-risk estimate.
McConnell went on to say that it is important that the estimation process is made rigorous, so that developers can trust their own estimates. He says that failure is usually thought of as an inability to meet targets, but if you analyse failed projects you’ll find that the developers often thought that those targets were unreasonable.
The reason developers don’t tell anyone is because they’re unsure of their own estimates, being, after all, just a guess, and that they hold no more value than anyone else’s estimate. If developers could trust their estimates, and have some way to defend them, managers could then create accurate plans, and failure could be avoided.
One possible implementation of these concepts is XP [extreme programming, for those who haven’t realised what this column is about — Ed]. McConnell mentioned that this filled most of his criteria very well, but that he prefers multiple estimation tools. In XP we only have one estimation tool, but our team culture and processes make that a very strong tool.
Also, XP is currently the only process that directly addresses McConnells’s concepts – which is one of the reasons XP projects have a lot more control than any others.
In XP we call our requirements “stories”, and these are very small to begin with – a sentence or two written on an index card; the team must be able to complete a story in three weeks or less (usually a lot less). Each story is broken down into engineering tasks, and we provide an estimate for each task, and then total these to provide the story’s estimate.
The total of the story estimates is the project estimate. Our estimates are in “ideal engineering days”, which we commonly call Gummi-Bears, a measure that never equates to real time (a developer may get only one ideal engineering day for every two calendar days).
This then is the basis for our project plan. We get the customer to then assign a value to each story, representing value to the customer. We organise our projects in iterations, lasting between one and three weeks each, and we know in how many gummi-bears we can complete each iteration.
We get a calendar, and draw our iterations on it. We place the story cards on the calendar, in value order, ensuring that in each iteration we have no more estimation points than we can do – remember, we know how many we can do, and we know how long each story will take.
We then plan incremental release dates. These are points in the project where the accumulated features of the system make it useful to the customer for some reason, and they decide to take a snapshot at that point. Often these are months apart, and the system will be used for testing, training and so on. Sometimes the system is deployed at this point, but that isn’t necessary. The customer chooses the frequency of these releases based upon their ability to make use of the system. We could provide an updated system weekly if that’s what they wanted; even daily, at a push.
If the customer doesn’t like the plan, they can change the value of stories and rearrange them on the calendar. What she can’t do is revise the estimates, unless she changes a story. If she does second-guess the programmers and reduces the estimates, she’s only lying to herself – because we would have left by that point. The estimates exist to allow accurate planning. We say to the customer, “We know the price, now how do you choose to spend your money?”
Of course, these are only estimates. When the time comes to actually build a story, then the developers who are doing it get to revise the estimate, based upon their enhanced understanding of the system, and the customer gets to revalue the story based upon the current state of the business. The variations we find here tend not to significantly affect the overall plan, because of the law of large numbers. Sometimes the estimate is bigger, sometimes it’s smaller – overall they balance.
Every release we update the plan and see how it looks. When we update we go through the process of updating the estimates, this time based upon more experience of the system, and the values, allowing the whole project’s worth of stories to be realigned with the current business need. In this way our overall plan remains capable of delivering maximum business value. This only takes us a day, so it’s not expensive, and the value it creates is well worth the cost.