Yesterday’s Weather: An Extreme Programming Planning Technique Using Story Points

Yesterday’s Weather is an Extreme Programming planning technique used to estimate the capacity of a Team based on their past performance. Yesterday’s Weather is a guide to help Teams neither under commit nor overcommit to a set of Product Backlog items during Sprint Planning. It is based upon the old story about developing weather forecasting software; if you want to predict today’s weather, all you need to do is repeat the forecast from the previous day and you have a 70% chance of being correct.

So does this work for software teams? In my experience, it does. If a Scrum Team is working in timeboxed Sprints of two weeks, they will likely deliver the same amount of working software in the next two weeks as they completed in the previous two weeks.  This is due to two very important, simplifying assumptions associated with Scrum.

1. The next Sprint has the same number of working days as the previous Sprint. If there is some type of holiday within a Sprint (like Thanksgiving, Christmas, Memorial Day, Fourth of July or whatever), then the Team’s capacity will be reduced since there are less days for hands-on coding. Yesterday’s Weather tends to fall apart completely when the Sprint length expands (or contracts) since there is not a linear adjustment on how much work a team can complete in three weeks (or one week). In these situations when Sprint length is changing, my advice is to complete two or three Sprint to allow the Team’s capacity to stabilize.
2. The membership of the Team is fixed from Sprint-to-Sprint. Yesterday’s Weather assumes that the same Team from the previous Sprint will work on the Product Backlog items in the next Sprint. When the Team expands (or contracts), Yesterday’s Weather is no longer realistic and should not be applied during Sprint Planning. Also, be careful about changing out Team members while maintaining the Team size. While people may look the same on paper with respect to skill set and experience, new Team members will not make an equal contribution as the previous Team member for about four to six Sprints.

So what does a Scrum Team do when their Yesterday’s Weather is no longer accurate? I would revert to Commitment Based Planning and go with the Team’s instinct on what they think is possible for the next few Sprints. Once the velocity has stablized, then go back to Yesterday’s Weather (if you need to).