Yesterdays Weather

The rule in XP is that you can't sign up for more work in an iteration than you did in the previous iteration. This is like saying that today's weather, to a very rough approximation, will be the same as yesterday's weather.

This keeps you from assuming this iteration will go substantially better than last iteration. It probably won't. Even though the thing that kept you from doing an ideal week's work in a real week last time (corporate off-site, vacation, flu, server crash) won't happen next time, something else will.

Also known as the Roseanne Roseannadana Rule, because "It's always something."

: "Life is what happens to you while you're busy making other plans." -- JohnLennon

So, as the project moves forward, you progressively do less and less work each iteration. Sign me up! I could use an "in-cube" vacation.

Except that it's just for making estimates. Sometimes you'll finish your tasks quicker than you estimated... so you grab some more work. This raises the bar for YesterdaysWeather for next time. A team with a velocity that is constantly trending downwards is probably a team with a problem.

From the XpMailingList:

On Thu, 2003-06-26 at 01:38, haralds wrote:

Hello, I am wondering about time estimation and when to justify the value of the load factor.

Most of us no longer use load factor. It has been replaced with "ProjectVelocity" combined with "yesterday's weather".

For instance, a developer estimates one task to be 6 ideal hours. Then after finally finishing the task, it took 12 ideal hours. However, he has been undisturbed and his mind has been at peace, everything going for him. In other words, he had underestimated the complexity of the task. In this case, I guess that the load factor should not be adjusted or should it? Or do you record 12 ideal hours (for your project velocity) and just accept that it was a bad estimate?

Velocity measures how much of the estimated work actually got completed. In this case, the developer completed 6 units of estimated work, so his/her velocity for that time period would be 6. Many of us prefer to call them units, or "gummy bears" so people don't confuse them with real hours.

Yesterday's weather tells us that the best prediction for how much work we can do in the next iteration is the same amount that we actually completed in the previous iteration. If we completed 6 units last time, it is likely that we will complete about 6 this time.

This is much simpler than load factor, because there is no math. It turns out to be at least as accurate, too. Essentially, velocity tells you that this person or team can complete the amount of work that they estimated at X units. It relies on estimates being consistent, not accurate.

It relies on relatively constant hours of availability. For example, if half the team is going on vacation for a week, you might want to predict half of the previous velocity. But this adjustment only needs to be done for large deviations. It should not be adjusted for a 2-hour company meeting, for example.

The only time you need to guess at a LoadFactor is before the very first iteration of a project. At that point, the estimates are normally in "ideal hours" or "IdealDays". So it's reasonable to use a LoadFactor of about 3 to predict the first iteration's velocity. As soon as that first iteration is complete, you have a real velocity to work with, and you can forget about load factors.

--KevinSmith

YesterdaysWeatherIsJustaStartingPoint

HistoryRepeatsItself writ small