Estimations are often very far off because those doing the estimations forget what is involved in completing a story. Often the estimation is done based on how long it takes to code it up. As you can see below, coding it up is just one of the tasks per story.

Even just doubling the code time is inaccurate. Why does a team that doubles the code time estimates still fall behind?

• Because they didn’t understand what is involved in the story.
• Because they don’t understand coding time versus work time

Reason #1 – You didn’t consider all the development tasks

There are many more tasks than just development. You need to know what these tasks are and understand them. You need to understand the risks each brings to meeting your goals.

Tasks to consider when estimating story time

First determine which tasks apply to a story. Then estimate each task individually. Then simply add up the hours. Your estimations will probably be more accurate and upper management will become aware of what tasks are slowing a story up.

Using this list can also help with getting tasks done at the same time as opposed to using the waterfall method. For example, if you are creating a new file, you can create an empty project, check it in and build and install can get working on their tasks while developer is still coding.

Let’s give an example:

So if you estimate based on coding, which is just 8 hours, you can see you aren’t even close. It will take four and a half times as long as you thought. If you estimate based on code and unit tests, 16 hours, you are still more than twice as long as you thought.

Note: I am not saying that these all have to be tasks on one story. You could break them up into separate stories. However, you will find that if Unit Tests and Automated Tests and these other tasks are separate stories, then the person in charge of prioritization of stories is now able to drop them in favor of other work and then your code will blow up one day and the developers will take some of the blame even if they shouldn’t. It is best if a story and all its tasks are 100% complete so you don’t ship half finished or a half tested product.

Reason #2 – You think developers code eight hours a day

Ok, so let’s talk about an eight hour day.

Most states have laws about two fifteen minute breaks (one ever four hours) so really, any employee is only going to work 7:30 hours a day. Ok, now add in the fact that it  usually takes five to fifteen minutes to focus back on work once back from a break. With lunch and two breaks that is 15-45 minutes. So now we are down to 6:45 minutes to 7:15 minutes. Ok, how long will be spent on email? 30 minutes to an hour. So now you are down to 5:35 to 6:45 hours of coding a day. Now factor in Stand up. 5-15 minutes, plus 5 to 15 minutes to get focus back and we are down to 5:05 to 6:35 minutes.

So on the best days a developer will likely code between five hours and 6 hours and 35 minutes.

Add a meeting or two in a day plus the refocus time after the meeting and development time is decreased further to 3 hours to 4 hours on meeting days.

So if you are assuming that your developers are going to coding 8 hours a day, you are in for a shock.

• Best Day: 5 hours to 6-1/2 hours
• Meeting Days: 3 hours to 4 hours

So add in scrum and sprint planning, story costing, and sprint retrospective, in which some meetings are longer than two hours and you lose a full day of development every sprint. So with a two week sprint, plan on 9 days of development at an average of 5 hours a day and you get 45 hours of development time.

• Average development time per sprint per developer: 45 hours

Now if you have a team of three developers. An inexperienced team might estimate with 45 * 3, or 135 hours. Unfortunately that probably won’t be accurate. Estimators will find that inevitably one of the team members has time off during a sprint. Remove 5 hours per day off (not eight). There also might be a holiday during the sprint. Well, a holiday means that 5 development hours per developer are not available, so that 135 hours becomes 120.

So lets put this into perspective. If you think that you have 8 hours a day for 10 days in a two week sprint for 3 employees and so you plan 8 * 10 * 3 and get 240 hours, and then you plan 240 hours of stories, you are only going to get half way done. This calculation is almost twice what in reality your team can do. If you plan this way, you will always be behind, and fail to meet goals and deadlines while working your developers to death.

Can you make up the hours by working the developers longer? Not really. The developers may end up putting an extra two hours a day in for 9 of the 10 days, but they will probably take one more 15 minute break on those days. Which only gets you about 1 hour and 30 minutes more per day times 3 developers times 9 days. This is 45 hours. 120 hours plus 45 hours only gets you to 165 hours. You are still 75 hours short of 240 hours.

So estimate accurately by starting with 50 developer hours per two week sprint (10 * 5 = 50) for each developer and subtract days off. Then estimate the work that can be done.

To make this easier for you, I have created A Spreadsheet for Sprint Planning that you can use.

Conclusion

If you fail to understand the number of development hours and fail to understand all the work for each development story, you will never be accurate, and you will always be behind and always be asking your developers to work longer hours, which will create a horrible work environment.

Understanding both of the above reasons above and estimating accordingly will provide accurate estimates. This will benefit the whole company. Upper management will see the true velocity. The quality of the code will be higher because the developers won’t be overwhelmed and stressed, which will result in lower bugs, maintenance, and support costs. Marketing will have realistic ideas of what is coming and what isn’t and won’t waste money getting ready for features that drop off a month before ship.