Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Thursday, November 02, 2006

Agile Estimating: How long is an ideal day?

About seven years ago, my first attempt at doing an estimate using agile terminology went something like this:

Me: "OK, I estimate this functionality at about 3 ideal weeks of effort"
Boss: "Uh...what is that in calendar time?"
Me: "Well, er, it's complicated, it depends on team velocity and planetary motion"
Boss: "Great, can you tell me by tomorrow?"

After doing some reading and thinking, I decided an ideal week was something like a "man-week", adjusting for daily distractions. For most people I've worked with, this adjustment factor (called a "load factor" in the original XP books...yikes) is somewhere between 0.5 and 0.7.

In fact, some studies suggest that the maximum productive time for most workers is five hours, regardless of how much time they spend in the office. Work that requires intense concentration, like say, software development, is more prone to productivity loss from distractions, phone calls, etc.

In other words, an ideal week for a single developer looks a lot like half of a "man-week". Looked at differently, a developer has a capacity (or velocity) of 0.5 ideal weeks per calendar week, or for a two-week iteration, about one week of ideal effort.

So a team of four developers of roughly equal capability would be able to implement about two ideal weeks worth of estimated effort in an iteration (of 2 weeks).

Another popular method of estimating agile user stories is to use a point system to measure the relative size. By using points, a team can estimate the size of a story relative to other user stories.

A 2-point story is twice as difficult to implement as a one point story, and a 4-point story is twice as hard again.

Personally, I tend to prefer the ideal time units, since it's easier to explain to customers, but I have heard reports that point systems have had good results as well after the initial confusion.

How do you estimate and why?

For more on agile tools and techniques:
(Tags: , )

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams


  • Currently I favour the "points" method of estimating. I find using "ideal weeks" continuously leads to the debate over "we can fit more in if you make your developers 100% effective, so do that"

    By Anonymous Anonymous, at 4:30 PM  

  • In one lot of estimating I did I was estimating days. I had a column next to it called the "PM factor", i.e. how much quicker I could do it because I had specified the module, and so had already got my head around it. For most things the factor was 1.5. After that my nickname on the project was "The Factor".

    By Blogger Paul Morriss, at 2:24 AM  

  • After getting over the initial hump, story points give you one thing that ideal days never can - hard facts.

    Our team can finish roughly 30 points of work in 2 weeks, and that is not a guess or an estimate. It's a fact that's been established by months of data. If you make the assumption that we estimate story points accuratley, then there's nothing left to discuss. The team can do 30 points - now pick and choose the 30 you want them to do.

    Establishing a team velocity is simply a game of variable reduction that leads to far more streamlined planning and estimating conversations. Planning is reduced to "how many more points can we add before we're near 30?" while estimating has become simple comparative estimates - is this item bigger or smaller than the 3 point item from last week?

    Mike Cohn states all of this in his book "Agile Estimating and Planning"...much more eloquantly than I have :)

    By Anonymous Anonymous, at 8:20 PM  

  • Both, it depends on where the company is "at" with Agile, I tend to find Ideal Days is a good starting point and then steer the team towards a points based approach. The issue being points is related to size, and Ideal hours is related to size for an individual, so 2 individuals could come up with 2 correct but different estimates, but it would be the same number of points.
    eg. two runners giving estimates over the time taken to run 5 miles will give different answers...

    By Anonymous Rob Elbourn, at 6:12 AM  

  • Isn't all this just playing a game to avoid saying what the people paying the bills really want to know? After a couple of iterations you know that your team of 10 can burn 30 points in 2 weeks. So 30 points costs a company 100 days of effort. So why not just estimate in days? I understand playing the storypoint game until you have enough data to get to days, but once you have days why note share that information? When I'm talking to the companies we're selling our services and software to, they don't want to talk story points. They want to talk days and costs.

    By Anonymous Anonymous, at 8:23 AM  

Post a Comment

<< Home