Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm thinking of things like:

  • designating a developer having say 6 hours out of their normal 7.5 hour day dedicated to the project, the rest for other work/company related activity (meetings, emails, calls etc), maybe a senior dev is less.
  • building in 20% contingency time to estimates.

What are the best ways to produce tight estimates and at the same time shield developers from management.

Addendum: I've been asked to help my current client with these types of issues. They are a really poor dev team with the business calling all the shots, scope creep, overlapping environments, priority changing at a whim etc. I want to help them get better.

share|improve this question
This might be better asked on the PM site. –  Bill the Lizard Mar 29 '11 at 13:12
In an agile world, this is relevant to developers, or anyone on the team. –  Andy Wiesendanger Mar 29 '11 at 13:59
6 hours out of 7.5 is pretty optimistic. You'd have to have that developer well insulated from distractions, administrative garbage and meetings. –  Joel Etherton Mar 29 '11 at 14:58
@Joel - totally, it was just the number that popped into my head at time of writing. I once had a team where all devs were down as 15 hours per week! –  Ozz Mar 29 '11 at 15:32
add comment

5 Answers

up vote 1 down vote accepted

A pet peeve of mine are arbitrary deadlines.

Project Deadline: the problem

Project estimation invariably leads to a date which becomes an implicit deadline. Missing that date, regardless of cause, often feels like a failure if it is not outright characterized as such. When you give a date you set expectations and when those expectations are not met it is natural for people to feel somewhat cheated or deceived. Team morale often takes a hit.

Project Deadline: blunt team management and it's cost

In my experience people want arbitrary dates because they want to use project management as a blunt tool to try herd developers into what to work on and how hard to work. So, the best case scenario is the team works to a deadline and get's it done early. The same performance you would generally get without a deadline.

The worst case scenario is, as anyone who has ever had a project go over a deadline knows. The closer you get to a deadline, the more shortcuts are taken. The more quality of code suffers. And generally the more morale suffers. It is idiotic to try and force people to work to an arbitrary date when you look at the cost. The outcome is you've produced bad code and made morale worse. You may even have some turnover as developers seek other places to work.

Just to reiterate:

  • Best case scenario is the same performance you get from the team without a deadline.
  • Worst case scenario is bad code, bad morale, and a bad experience all around.

Projects Without Deadlines: a better way

I don't give dates unless there is a hard deadline. The release has to align with a marketing campaign, a particular event, etc. However, the question then becomes how to we (the development team) interact with others? How do they know when their requested piece of work will get done?

Frequent Releases: Vertical Slices and Velocity

Firstly we track all the work that is done. No work is engaged in that is not feature or a bug fix. Everything is done as a vertical slice. So when a feature is completed, it is releasable. We release biweekly currently, but have in the past released weekly. The result of this is everyone sees not only progress and completed work, but they get a sense of rate of work as well. Indeed we even have a weekly velocity (we use the idea of continuous weekly Sprints), along with a 14 week mean, standard deviation and median.

Public Priority List

Second we have a priority list that is public and we only work on the highest priority work. I manage the list, and make calls about priority informed by various factors. I double check with my manager.

So people get to see there work in relation to others, and they get to see each piece as it is complete released (on the biweekly release). So far it seems to work, and best of all no arbitrary dates.

share|improve this answer
awesome, thanks for that. I am used to working in Agile environments and am pushing them to get to 2 weeks sprints instead of the large 6 month release schedules. –  Ozz Mar 29 '11 at 16:52
You say you have no deadlines but then say we release biweekly or weekly in some cases. That sounds like an arbitrary deadline too me. Also, what happens when you don't hit your biweekly or people are rushing to hit their biweekly? Probably the same thing as you describe not liking about the arbitrary deadlines. –  Dunk Mar 29 '11 at 19:27
@Dunk We release whatever is completed. Since every feature and bugfix is done as a vertical slice they are releasable when they are complete. If there are no updates we don't do a release. –  dietbuddha Mar 29 '11 at 22:05
Sorry, I think I read something into your answer that you didn't say. When you said biweekly, my mind immediately jumped to SCRUM sprints. Which I was pointing out has all the deficiencies that you were claiming as problems, just on a more frequent basis. –  Dunk Mar 30 '11 at 13:30
@Dunk No worries. We don't use Scrum. We have our own process that arose out of Agile and Lean. We got rid of what didn't work for us, and kept what did. –  dietbuddha Mar 30 '11 at 16:08
add comment

Previous performance is the best predictor assuming you have valid data. It still may not be accurate enough, but the more cumbersome you make gathering data to gain accuracy, you risk not capturing it at all.

IMHO - being focused on what is important is the best way to manage your time and hit due dates.

share|improve this answer
thanks Jeff - first paragraph, that kind is difficult to track over time I find, due to changing technologies, changing personel (leaving, moving to different project, being promoted etc etc) –  Ozz Mar 29 '11 at 15:36
add comment

That's a good start @James, but consier that administrivia interruptions don't all come in a convenient 1.5-hour block, they tend to be sprayed throughout the day and have impact far beyond the nominal time for recovery.

Also, 'hours' is not a terribly meaningful measure of achievement. An hour spent staring at the monitor watching the clock waiting for lunch to get some Starbucks to wake up enough to have the will to tackle the bug that kept you awake all night is not the same as an hour spent at Starbucks debugging like a maniac while IM'ing four friends for help with a tricky I/O blocking and race condition.

While a 20% margin might account for simple errors and oversights, but not for major omissions and mistakes (and platform "gotchas!")

Finally, as @Bill suggested, the PM site would be a better place for this question.

share|improve this answer
Thanks! you're right about interruption blocks. Most places I have worked calculate tasks estimation in hours, that's why specifying how many actual hours worked in any 1 day is good for trying to extrapolate out when your schedule ends. I guess we presume up front our devs aren't sitting looking out the window for an hour. Maybe I need a 1% laziness metric on top? :-) –  Ozz Mar 29 '11 at 15:35
@james: on a good day, with few interruptions and no stress, the average developer will probably have about 4-5 productive hours of work. If you're lucky. If your team works from home, this number may be higher. Or not. This is why estimates are made in "ideal days" or "ideal man-hours", and then multiplied by large margins. Some research indicates that 4.5 hours (three 90-minute bursts of effort) is the ideal daily output. –  Steven A. Lowe Mar 29 '11 at 22:06
add comment

Depending on the size of your team(s), there are various project management methodologies which can be used to help establish realistic and achievable deadlines.

The most popular Agile methodologies are SCRUM and Extreme Programming (XP). Both have best practices and revolve around principles which are just common sense.

20% is a number I've also seen in the past which in practice is quite realistic. This number can be diminished if developers don't need to switch frequently between tasks.

Personally, adopting SCRUM really helped my team establish realistic timelines and milestones. It also helps communicate our objectives to the rest of the company. (the "non-techies")

share|improve this answer
Thanks @TekNullOG - I am pushing them towards Agile as I think it would be ideal for them. –  Ozz Mar 30 '11 at 14:03
add comment

The addendum is a different beast than the OP. Now you're talking about how to educate management on how software development works, and what's been recognized as setting things up for failure, such as scope creep. That's quite different than helping a team get good at estimation and time management.

share|improve this answer
erm... it's the reason I asked the question, just adding more context. The dev/PM team just bend over and let management push them around, which, yes is a wider issue, but they have no idea about estimating properly, always over run on tasks (ie. the 6 hrs out of 7.5 thing). –  Ozz Mar 29 '11 at 16:49
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.