How should I account for non-coding time when estimating duration of a coding task?

Question

I was wondering whether this approach I am doing to scheduling dev work on a day to day basis is correct. In which I assume that instead that a developer has 8 hours a day to do coding, they actually have less.

Situation:

• I already have list of specs and broken them down to appropriate tasks and estimated hours to complete them.
• Now I want to fit these tasks and their appropriate hours in the calendar so I can find the dates on when these specs can be completed.

My thinking is that assuming a standard 8 working hours a day is flawed because one does not always code 8 hour straight. So after taking into account for non-code time involved for my team and myself such as

• Daily scrum (0.5)
• Lunch (1.0)
• Misc Meetings/Discussions (1.0)

I would assume that a developer would really only have on average 5 - 5.5 hours of solid work. So I am scheduling on that assumption. Would this be the right approach or a better way to take into account non-coding time? Because simply saying that someone has a day to finish Spec X doesn't mean they have 8 hours to finish it, isn't it?

Answer 1

So you are using hours in a day but talking about duration. These are two different estimates and cover different things. You are on the right track, however, in terms of allocating the right utilization per resource. Full-time is something less than 8 hours a day. It can range from 35% to probably not higher than 75%.

While productive work is less than eight hours, the caveat to this is, 'where are they charging non productive hours?' Likely, they will hit the same charge codes even when attending meetings and not coding. In this case, full-time is 100% and you wouldn't have to worry about resource utilization.

Personally, I estimate in days and duration, load the resources, and let the hours calculate out. I find this the easiest way to estimate and manage.

Answer 2

It is common practice to schedule developers at 75-80% of their available hours. Available hours do not include vacation time, lunch, or any other time that the developers are not expected to be working.

Developer time is often consumed by things other than pure development activities. Meetings and scrum as you cite. But also communication with other developers, unexpected technical problems, little project administration items that weren't originally on the schedule but probably should have been (test data creation, test creation, integration with other developers, documentation, helping other team members, etc).

Hopefully, your scrum is not a half hour every day. They should be in the 5-15 minute range. And certainly developers will have to attend design meetings and those kinds of things over the course of the project, but are your developers really spending an hour a day in meetings?

Answer 3

From experience I have found that focusing on time, in units of hours is not a good idea.

Base all your estimates on feature size and larger scale measure.

For instance, at work we use numbers of 1, 2, 4 8

• 1 means trivial (< 1 hour)
• 2 means 1/2 day or so
• 4 means half a week
• 8 means a week or more

Also make sure that estimates are done with input by the actual programmer(s) themselves. Some folks will complete a task in 20 minutes that will take another programmer 4 hours. This is much underestimated in the industry.

Make sure you allow for estimates to be completely wrong. When a target is not met, and that repeats, consider if the estimates are right.

When broad estimates are not met, always make 'what did we do wrong in the estimate' the first question. Not "why did we miss the deadline' which will but the programmer on the defensive and encourage them to 'get the stuff written one way or another by the deadline', i.e. not pay attention to long-term quality. Today's 'met' deadline quickly becomes tomorrow's bugs and errors. Allow time for downtime. You mentioned lunch and the like but what about:

• computer crashes
• editor or IDE upgrades
• OS updates
• prototyping
• the unexpected crap that comes up all day long as a programmer...

Programmer often put in many extra hours, (mistakenly) feeling that they are responsible for the extra time that the task is taking, whereas in reality it's just the estimate that was off as it didn't take into account the unexpected.

Many hard-core programmers end up spending as much if not more time 'finishing up' outside the office. Make sure that is accounted for as it matters in the end.

Answer 4

Since you seem to be using Scrum as your project methodology, you should have sprint team velocity information. If not, you should start gathering it. You should also have story points estimates for each of the story as this is part of the Scrum planning and backlog grooming process.

Assuming the above is true, the scrum team should be able to estimate itself how much work they can do for a given sprint and then commit to that load.

In addition, the team members should be the one providing the duration estimates on the tasks that they will be handling.

This approach will automatically account for non development activities during a sprint and after a few sprints should give you enough confidence in estimating and planning for future sprints.

Answer 5

I think it depends on how specific you're being, and where you're reporting it to.

Are you asking about how to report to the client? Are you asking about how much time to tell the devs they've got? Are you looking to plan the schedule?

In the end, when you refer to a task you have to include all that goes into that task, So if you're talking about coding, there.s time for reading the reading the requirements, time for thinking about the correct approach, time for the actual coding, and time for the review of what they typed, among other things. And then throw in some meetings to make sure they're clear on changes, mods, interaction with others deves, etc.

I would include all of that under "coding". To try and break it out is inviting problems. Then you're into how long is the meeting, why is the meeting, do they need to be at the meeting, was the daily stand-up too long, did they take a long lunch, etc.

Stick to 'averages', and agreed upon durations. As David said, figure 75% or so of an 8 hour day for productive work, the rest taken up with minutiae.

Trying to get more specific means that eventually you'll be counting keystrokes per hour. :)