Thanks to Ksenia Shulga and Michael Livshutz for their assistance with this article.

“When will the project (or feature) be finished?” – this is the main concern of any Client.

If you ask the developer about it, most probably the answer will be something like “I don’t know”, “The time frame is unpredictable” or “It’s too early to talk about the end date” etc.

When you find yourself in the role of software customer, consider applying these methods before running these questions past your developers. These methods will help see the future with more clarity and decrease the risk of blowing past the delivery date even under the toughest circumstances, such as when using unfamiliar technology or in a totally new area.

Theory

The developer will avoid committing to an estimate not because he has something to hide, but because he fundamentally cannot make an accurate estimate. Technical complexities can pop up at any time. Misunderstanding of the task can occur as well. A simple change of the task list during the development process can happen too. Frankly speaking, these risks drive the fear of being held accountable for the estimates given to the Client.

Generally, a developer is hired for his knowledge and experience in a particular technology, not for his decisiveness or talent to predict the future. My guess is that talented predictors are gainfully employed as stock brokers.

The closer the deadline, the more likely you will hear the developer say: “Nearly all the tasks are almost completed and we will be done any day now” – all this is a real nightmare for the Client. There’s a popular wisdom that “90% of the whole project take only 10% of the whole schedule”. Based on my experience, junior developers’ estimates are too short by 10 times. Senior developers make frequent estimation errors as well, but at least in my experience their estimates are too short by less than three times.

The saddest thing here is that everybody overestimates their own abilities and as a result the project is finished with delay rather than ahead of schedule. To crown it all, quite often the delay in schedule is not perceived up to the very last moment. My frequent goal is to prevent such situations and make the estimates clear and useful.

Further on we’ll discuss the steps that one needs to follow to get realistic estimates. Besides being realistic in developer’s eyes, the estimate must be agreed to by both the Client and developer.

• Come up with the list of tasks or user stories.
• Get the estimates from developers about the complexity of each task
• Figure out the date of the project’s completion

The list of tasks usually already exists by the time when the estimate is required. It may be an early rough version, but it is good enough for initial estimation.

How to Estimate the Complexity of Each Task?

Tasks can be different. They can be as simple as “Implement new user registration” and as complex as “add a support to the new equipment prototype whose drivers are still in alpha while programming in a new language”. It’s evident that estimating becomes most difficult with the latter.

Below I provide several methods of estimation that suit any task.

• 1. Based on my experience with previous projects, I can provide minimum and maximum values measured in days or hours. For example, “the page for editing of user’s info will take 2 days at the minimum. It will take less than 3 days for sure”. As a result, we arrive at a time frame that is good enough for an initial estimate. Unfortunately, this method can generate large inaccuracies, depending on similarity of current task to the estimator’s previous experience.

  The method becomes more reliable if the same task is estimated by 2-3 people independently. In case there is no a second person on the project, the same person can write two estimates on different days. These two estimates are then compared. This method is best for preliminary estimates. One more interesting approach of estimating tasks based on one’s own experience is described by Michael Lant in Estimate How Long It Will Take To Complete Your Agile Project

• 2. My favorite method is planning poker. In a nutshell: the team gathers together and goes through tasks one by one. Every team member estimates the same task independently and records a complexity score. After that all the estimates are revealed and discussed. Those who came up with the most minimum and maximum estimates provide explanations. “We already did integration with this payment system on another project and it took us 2 weeks” or ”I know a freeware plugin that will solve the problem in 2 days”.

  Then, the team estimates and discusses the task again until everyone records the same score. An outstanding side effect of this method is that all team members learn something about every part of the project. As a result, the team is better protected against disruption due to a dismissal or sickness of one team member.

• 3. Another method is gradation of tasks by complexity. It is helpful when the team is overcautious in providing any numeric time estimates. In this case, we print out the cards with the task description and ask the team to lay cards out in the order of complexity growth. After that it’s easier to estimate the task: “This is the easiest task, let’s rate it by 10. This one is a bit more complex, but still very simple, let’s give it a 12 here. Whoa, and this task is way complicated, we’ll rate it 20”.

What Units to Use for Estimating Complexity?

There are 2 basic methods that have proved themselves in practice. They are estimation in days and estimation with story points

Estimation in days

From the Client’s point of view, it’s better to use working days or hours. Here the developer should say something like this: “The project will be delivered in 150 working days – on October, 20, 2010”

This method unfortunately leads the developer into making a wrong estimation. Subconsciously, every developer is fears the question “How long will it take?” because his estimate is likely to be inaccurate. He imagines being reprimanded by the Client: “This feature took you 30% of the time more than what had been planned. You are a bad programmer” or “This feature took you 1 day to be implemented and your estimate showed 3 days. It was evident back then that the task was simple. Your are a bad estimator”. The developer faces two unhappy options: the task completed with delay equals to a “bad programmer”, the task completed ahead of the schedule equals to “a bad estimator”. Thus most developers hate this method and avoid using it.

Hours can be used instead of days, but that does not change the method’s main point.

Story points estimation

Assessment of project duration in days is good when preparing a rough estimate right before signing the contract and starting the work. For more accurate estimation it’s better to use “abstract points” or “story points”. In this case the team rates the complexity of every task with numerical value. If the rating is high – the task is complex and will take lots of time, if the rating is low – the task is easy and should be done fast.

A good psychological explanation of story points advantages was given by Mike Cohn.

The way of to convert story points into working days will be described below.

Next Step: Make Estimation More Accurate as the Project Moves Along

Now we already created the list of tasks that needs to be done to finish the project. The complexity of every task has been determined as well. Throughout the project’s progress the list will be changed and supplemented, but in general it will stay the same.

If you used the method of estimation in days

Let’s assume that we’ve worked on the project for some time and completed a number of tasks. If we estimated the tasks in days, then we can calculate the ratio of estimated days to actual work days. This ratio will become our current correction factor. For example: We planned to implement the “reports generator” in 5 days. In reality we spent 7 days. The correction factor will be – 7/5=1.4

This correction factor must be used for updating previously given estimates. However, one can easily get confused here with “actual work days”, “planned work days” and “planned days after the correction factor introduction.” This is why I prefer using story points method.

If you used the “story points” method of estimation

First we calculate the same correction factor as previously, but expressed in story points. We calculate the sum of story points for already completed tasks and divide it by the number of working days.
Example: “The initial estimation for reports generator was 14 story points and it was finished in 5 days. The velocity will be: 14/5=2.8 story points per day”
We take the sum of story points in all uncompleted tasks and divide it by velocity.

Example: The team estimated a project with 250 story points. 14 out of them are already completed. The velocity is 2.8 story points per day. That means that 84 working days are left till the projects’ completion (250 -14)/2.8=84.

When the project progressed to 20% – 30% point of overall time, we can already calculate several different velocities: “for the last iteration”, “for the last week”, “average velocity for the whole project”, “average velocity for the last three weeks”, etc. The delivery date can be calculated for each velocity. For example, our calculations based on these velocities will show: “October 11”, “October 15” and “October 29”. Usually, the Client is okay to know the time frame. In the example provided, the time frame will be between October 11 and 29. By the way, the closer the project’s end, the closer minimal and maximal estimates will be. The result of calculations is sent to the Client weekly. If something goes off-track, the Client is always in the loop.

If the Client likes charts, then the estimate can be transformed into in a burn-down chart.

Burn-down charts are well described by Alistair Cockburn, one of the founders of Agile Development.
Here’s an example of the burn-down chart from Wikipedia:

New Tasks

As we all know, new tasks usually appear in the middle of the project. The reasons can be different: either forgetfulness or mutual misunderstanding between the Client and developer.
Here is a typical situation

Client: Our website does not work on my old home PC. Please fix this bug by tomorrow’s evening.
Developer: We do not support IE6. It’s not on the list of the browsers we discussed. Actually, we do not even have the list.
Client: Well, I need IE6 support too!

After that the team estimates the task “IE6 support”. Let’s assume it is 35 story points. 12.5 days will be spent on it (35/2.8=12.5). The Client is informed about that we will have it 12.5 days from now. If the Client is okay about the date – we proceed working; if not – we have to do something else. Either we drop IE6 support or some other task can be eliminated, or the team of developers can be augmented.

Restrictions

The methods suggested work under the following assumptions:

• New tasks are added and the planned tasks are changed evenly throughout the project. Roughly speaking, the managers on the Client’s side cannot be changed.
• The team is more or less stable throughout the project. There are no dismissals and the core team members do not take long sick leaves. There’s no extensive staff augmentation either. Generally, introduction of new team members, especially at the very end of the project, is a whole another topic. I recommend the famous book “The Mythical Man-Month” by Frederick P. Brooks for a deep explanation of risks of extensive staff augmentation.
• Technologies newly added to the project are more or less similar. If we used well-known libraries for the first three months, but the next month decided to use an alpha version library with experimental equipment – well, then the method will fail on this stage.

Conclusion

The methods suggested above allow us to decrease the risks of wrong estimation for most projects, even the ones launched in new areas and/or with new teams. Continuous adjustment of estimates to actual performance of the team plays the key role throughout the project.