As discussed in a previous blog, The Perfect Estimate, providing software estimates is one of the most challenging aspects in the software industry. There are many reasons for this, not the least of which is the challenge of estimating the unknown. Unlike many other construction activities, like erecting a skyscraper or building a ship, software projects often involve new combinations of technologies (at least for those on the project) assembled in unique ways.

The more a task resembles a previously completed task, the easier it is to estimate. Ideally, metrics kept about the previous task will include time spent on various activities and the total time overall. When estimating the new task, you could analyze which activities are likely to change based on completing the previous one and derive an estimate for the new task.

In order to best illustrate the challenges of software estimates, I will use the time-proven technique of the parable.

The Parable of the Cave

Two people stand before a cave. One is the sagely manager of a cave exploring company who’s wisdom is only exceeded by his wit, charm, and humility. Let’s call him, oh, “Scott”. The other is a cave explorer of indeterminate gender who bears no resemblance to any programmers past or present that this author may have worked with and whose size may be big or little. Let’s call him/her “Endian”.

“Endian,” said Scott in a sagely voice that was both commanding and compassionate, “I need you to explore this cave. But before you do, I need to know how long you think it will take, so that I may build a schedule and tell the sales team when the cave will be ready.”

“Great Scott,” replied Endian using the title bestowed upon Scott by his admiring employees, “how can I give you an answer when surely you know I have never been in this cave before? The cave may be vast, with deep chasms. It may contain a labyrinth of underwater passages. It may contain fearsome creatures that must first be vanquished. How can I say how long it will take to explore?”
Scott pondered Endian’s words and after a thorough analysis that might have taken days for others but was completed in but a moment for him, he replied, “Surely this is not the first cave you explored. Are there no other caves in this district? Use your knowledge of those caves to form an estimate.”

Endian heard these words and still his doubt prevailed. “Your words are truly wise,’’ said Endian, “but even within a district the caves may vary, one from another. Surely, an estimate based on the size of another cave cannot be deemed accurate.”

“You have spoken truly, good Endian,” replied Scott in a fatherly, supporting tone that lacked any trace of being patronizing as certain cynical readers may think. “Here, take from me this torch and this assortment of cheeses that you may explore the cave briefly. Return ere the morrow and report what you have learned.”

The parable continues like this for pages, as parables are known to do. Let’s see, Endian enters the cave…something about a wretched beast of surpassing foulness…he continues on…hmm, that’s what the assortment of cheeses were for. Ah! Here we go.

Endian returns to Scott, his t-shirt ripped and his jeans covered in mud. Being always concerned with the well-being of his employees, Scott offers Endian a cool drink, then asks, “Endian, what news of the cave? Have you an estimate that I can use for my schedule? What shall I tell the sales team?”

Endian considers all that he has seen and builds a decomposition containing the many tasks necessary to explore the cave based on his earlier reconnoitering. He factors in variables for risk and unknowns, and then he responds, “Two weeks.”

Applying this Wisdom

To truly appreciate the punch line, you do need to check out The Perfect Estimate.

The point I’m trying to illustrate is that estimating software development is like estimating the time needed to explore a cave you’ve never been in. You don’t really know until you get in there. Still, there are techniques that can help.

First, draw on your experience. Even though technologies may be very different, few automation problems are empirically new. They bear resemblance to other things we’ve done in the past.

Expect the unexpected! Make sure you factor time in for the unknowns. If your schedule only contains the things you can think of, then it’s certainly going to fall short when the unexpected arises. There will always be things you don’t know to put into the schedule.

Provide estimates that are ranges rather than just a single duration. If a task can take 2 to 4 weeks, provide it in that manner. If your project planning software cannot accomodate date ranges, enter the task as 2 weeks and then put in a secondary task for another 2 weeks to account for this. I like to name these tasks, “risk factors”. So, if I have a task called, “Integration Testing”, I would add another called, “Integration Testing, Risk Factor”. This way, I can specifically see how much time has been set aside for this variability, and I can see what happens to the schedule if I increase or decrease that amount of time.

Make your estimates as fine-grained as possible. An estimate for a task that only needs a few hours is far more likely to be accurate than an estimate for one that will need a couple weeks. By making your estimates as detailed as possible you not only improve accuracy but the work necessary to create a detailed estimate will often turn up tasks you might otherwise overlook.

Even if your manager only wants an overall estimate, you should do a detailed decomposition to make sure you build the best estimate possible. This decomposition will also serve as a guide during your work, both as a checklist to make sure you haven’t forgotten something and as a status check to see if you are on time. This can help you timebox activities, applying the available time to a task. Projects can run over due to time spent waffling on design decisions. Timeboxing tells you when it’s time to make a decision and move on.

Build your decompositions with tasks that are either complete or incomplete. When tracking progress, don’t fall into the trap of recording activities as some percentage complete. A task is either finished or not finished. Showing partial completion leads to a false sense of security.

Use incremental and iterative processes. As in the parable, sometimes it’s useful to make a quick, preliminary exploration in order to build a more comprehensive estimate. Continue to refine your estimates and the overall plan. The closer you get to the end, the more accurate your schedule should be.

Work on the riskiest part of the system first. Too often projects run over when someone discovers a large problem in the final stages of the work. Assess the risk of each portion of the work and tackle first those parts that are most likely to exceed their estimates or induce changes in the rest of the system.

Lastly, it is absolutely critical that an environment of trust exists between the development team and the rest of the company. Your job should be to deliver the best estimate you can with appropriate risk factors identified. Too often estimates are inflated to make sure that we can hit them. Equally often, due dates are set artificially early to allow for overages. Both of these strategies prevent the company from building an effective plan for this project and developing appropriate contingencies. Worse, these constraints sometimes lead to poor choices and compromises during development that add further risk.