Moved here from PlanningGame:

''Ron-- I explain it now by saying that the estimates are in terms of tokens (I like gummi bears), and the team gets to say how many gummis they can produce per month. This keeps you out of crazy arguments about why you only engineer 1/3 of the time, which is not what the LoadFactor is saying, it's just a ratio from one measure to another (the calendar). Do you like this better or your edits (which are fine)?''

''Kent-- I see the point about the load factor arguments being reduced, but I don't know how to tell someone how to estimate in bummi gears. Also they seem just a bit frivolous and as you know I am a serious person. Starting off on the first CommitmentSchedule I can say "estimate in ideal weeks" and they have a clue. How do we bootstrap bummi gears?  Why not write it up the other way under the existing one, and let's see how it works?''

Frankly gents I ''like'' Ideal Weeks, because I can estimate in Ideal Weeks, other developers can too, and it gives us a nice conservative way to start dealing with LoadFactor. Why fix it if it ain't broke? --PeterMerel

Why not use money in stead of IdealWeeks (you can even display it in U.S. Dollars, Euros, or Yen at the current exchange rate on a web site) and assume there is no problem distributing the project among n developers. I am only half fidding - it might make management accountable to finance. --TurlochOTierney

The broken-ness is that it is so tempting to play with the LoadFactor to make the final date come out "right". I heard a story of a project that had the developers scheduled for 4.3 hours of productive work a day. The schedule started to slip so they changed the factor to 5.3. Problem solved! For a month.
If you can resist this temptation, there's nothing wrong with IdealEngineeringTime. --KentBeck

Just as Kent says, Peter. The scenario is that you do a schedule, it shows a date that management doesn't like. They say "What's this 3? Make it 2.5 and it will all work out."  Towards the end, maybe you have data. But the IP factor doesn't convert to the CS factor even then.  It's hard to resist saying "we'll try".  --RonJeffries

With respect then, I think you're fixing the wrong thing. You've said all along that LoadFactor is supposed to be a measured property, not a specified one. It's a metric, right? You can no more ramp up a metric by dictating than Canute could order back the tide. You can tell your developers, "work harder, work longer, do it for the gipper, I want to see that LoadFactor move, damn it!", but you can't tell them, "the LoadFactor is now 1. Good Day gentlemen." any more than you can tell them, "It is now summer. Bermuda shorts are required to be worn in office hours."

But if your organization is telling you that they can't abide your process, and you still have the faith in your process that I think you have, then maybe you need to move your development process some place where it is appreciated. In other words, stick to your guns, damn it. --PeterMerel

Easy to say, Peter, but as we all know, very hard for developers to do. Management can be really good at making developers feel guilty for being human. Nonetheless, I prefer the ideal days formulation, as I discuss in GummiBearsConsideredHarmful.  --RonJeffries

What's so ideal about an ideal day? It's just a day devoted to development without interruption. We only use it because it is what comes to mind when a developer is asked to either recall past effort or estimate futures. Think about where the extra time goes. I don't count time spent making obvious corrections in ideal time because developers don't remember it as such. That doesn't mean we don't fix bugs. It means we count bug fixing against our "productivity" as measured by load factor. Same with doing backups, or clearing printer jams, or catching up on office politics. By "ideal" we mean idealized in our memory. It's how we think when scheduling, not how we work or even want to work. -- WardCunningham

In my experience it helps to present ideal time in hours.  Seven people for three weeks at a load factor of 0.5 is 17 ideal days or 136 hours.  People just don't seem to query the figure presented as hours: I'm not sure if this is because the arithmetic isn't so obviously strange, or because of the pseudo-precision of three significant figures. -- DaveCleal

''How do you get 136 hours from seven people for three weeks at 0.5?  I can think of a lot of ways to calculate an answer, but none of them that come up with 136 hours.  (This is a serious question, there must be something I'm missing.) -- RandyKramer''

The answer is 17.5 ideal days ''per week'':  7 people * 5 days/week * .5 LF = 17.5 ideal days/week. Round to 17, then convert to hours: 17 ideal days/week * 8 ideal hours/day = 136 ideal hours/week.

Another thing: we use a variant of the PlanningGame with great success.  One thing that led us to it is that for us, ''Business'' is actually lots of independent Players with conflicting priorities.  We always use DateDriveCommitment, allocate each player some ideal time, and then invite them to negotiate with each other.  Getting out of this crossfire is valuable to us poor developers.

We also allocate the developers around 10% of the ideal time. I've seen elsewhere that the C3 team have dedicated whole cycles to developer-selected work: for us it works to do it in background.  -- DaveCleal

See NebulousUnitOfTime