Software Estimation

“Don’t have any history? Make your own.”.  That’s what I recently told a software development team at a mid-sized firm in Kansas City that was struggling (and under pressure) to make accurate estimates. In other words, management was looking for some predictability in their ability to forecast product release dates to manage customer expectations which depended heavily on the intelligence it was receiving from the software development group. One of the first questions I asked when I was brought in to discuss the planning and estimation for a new product with a team that had been assembled specifically to do the development was, “How does this compare with other products you have developed?”.  There was plenty of discussion about the technical similarities and the business domain particulars but there was little insight otherwise. Several of the team members had not worked together before which created some uncertainty and this organization did not track time to specific projects. Add to that they were working with some new technologies that they would have to become familiar with. So I asked if anyone had ideas on how we might estimate this particular product the answers included, “Shoot high and say 2,000 hours +/- 20%.”; “Tell them it can’t be estimated.”;  and “ Count the number of forms, fields and rules and say on average they’ll each take X hours.”. Finally, the one I was looking for. “Wait until we’re done and then we’ll tell them how long it took.”. That earned the biggest laugh but the laughter quickly faded when I said, “Excellent, let’s do that!” with a straight face.

One of the most effective software estimation tools I’ve used on projects and presented in workshops to explain software estimation (especially with new team members, new technology and/or absent historical project metrics) is the velocity metric.  It’s a rather mature concept in estimation in general but has gained particular prominence in Agile software development methodologies.  So I explained how we were going to make our own history and then we reassembled as a group a few days later and I delivered the typical estimating and planning workshop to the team. After we finished a great lunch of legendary Kansas City BBQ, I began moving boxes around the room.

I first set a full, large box of differently sized cups at one end of the room and a large empty box at the other end and handed each participant smaller, differently sized shoe boxes to use to carry cups from one end of the room to the other. I then asked each participant to fill their shoe boxes with as many cups as they could hold (without stacking the cups) and timed them to see how long it took to move the cups. We did this a few times and calculated the average length of time it took as a team and counted the total number of cups moved. We then took that average (e.g. 10 cups) and counted the total number of cups remaining in the big box to move (e.g. 100) and predicted that it would probably take the team 10 more rounds to completely move all the cups. In a few moves we “created enough history” to accurately estimate the length of time to move the remainder of the cups. We then continued to see how long it would actually take and as we proceeded with round after round I introduced a few obstacles. Literally in some cases as I set chairs in the way (delayed decision or other constraint) making it take a bit longer some rounds. One round I gave some of them smaller boxes to carry cups in (resource/capacity issues) and I added more cups to the backlog box all to illustrate the impact on velocity. When they were done, it took 11 rounds instead of 10 as they had predicted. Some rounds took longer, some shorter but the average velocity was still close to 10 cups per round. Each cup of course represented a software feature that needed to be built.

Then the inevitable question was asked, “But management wouldn’t allow us to work a few rounds (iterations/weeks)  just to estimate the software—would they?”. Thankfully the answer in this case was, “Yes.”, since I had already sold this to management as a highly-effective way to estimate cost and predict schedule. We proceeded with the project on that basis and the team is now tracking within 5% of the original average velocity they calculated after the first few weeks and management has an investment and schedule they can count on.

As you might imagine there are many more details moving from cups to software including getting some sense of the “size” of the cups relative to each another, but once you’re sold on the fundamental principle, it’s well worth trying on your next project.