What is Yesterday’s Weather?
Yesterday’s Weather is an estimation technique that originated with eXtreme Programming (XP). It takes its name from the idea that predicting today’s weather based on yesterday’s tends to be surprisingly accurate. In much the same way, it has been observed that predicting that a team will accomplish roughly the same amount of work this Sprint as they did the previous Sprint has some predictive power.
What’s the Benefit?
The principal benefit of Yesterday’s Weather is that it saves time, in that it’s a simple exercise to collect data about one or recent Sprints that a team completed.
When?
A couple of common use cases for using Yesterday’s Weather:
- For an existing team that has been working together for at least a few Sprints
- For a new team that is doing work that is similar to the work that an existing team has been doing (provided that both the new team and the existing team are similar in terms of size and skillsets)
Who Attends?
The people who are present when Yesterday’s Weather comes into play are the same people who would be present for any Agile planning conversation:
- Everybody on the team (all of the Developers, to use Scrum parlance)
- A Product Manager / Product Owner
- A facilitator (typically a Scrum Master, if it’s a Scrum team)
Inputs
- Data about how much work a team has done during several recent Sprints (most often expressed as its Velocity)
Outputs
- A projection about the team’s capacity for an upcoming Sprint (in a Sprint Planning context), or for several Sprints (in a Release Planning context)
Preparing for Success
When using Yesterday’s Weather, it’s important to understand that there are numerous variables that can affect a team’s capacity, and how much work the team actually produces. Thus it is helpful to use Yesterday’s Weather with complementary techniques, such as Probabilistic Forecasting.
Execution
- Review the amount of work completed over the past three Sprints and calculate an average based on that data, being sure to also account for:
- Anomalies in the data. For example, if the team averaged 6 user stories per Sprint the past three Sprints, but one of those Sprints was the week between Christmas and New Year’s, consider omitting that Sprint from the calculation, possibly replacing it with the prior Sprint.
- Significant changes to team composition. For instance, if a team’s 3-Sprint average is 9 completed user stories, but two team members are going to be out half of more of the upcoming Sprint, take that into consideration when planning team capacity.
- When the team has settled upon a capacity, use that number as guidance to plan the upcoming Sprint.
