What is Yesterday's Weather
Yesterday's Weather is a Scrum Inc. pattern for determining how many points a team should pull into an upcoming Sprint.
The principle is simple: the best predictor of what a team will complete next is what it completed recently.
Instead of relying on gut feel or optimistic forecasting during Sprint Planning, Yesterday's Weather uses actual delivery data to set a realistic Sprint commitment.
The result is greater predictability, less overcommitment, and increased trust with stakeholders.
Why It Matters
Most teams don't struggle because they lack effort, they struggle because they overcommit.
When teams rely on intuition instead of data:
- They pull in too much work
- Miss Sprint Goals
- Lose confidence in their planning
Yesterday's Weather replaces guesswork with evidence.
It creates a simple feedback loop:
- What did we actually finish?
- What should we commit to next?
Over time, this stabilizes delivery and makes performance predictable.
How It Works in Scrum
Yesterday's Weather uses a combination of historical velocity and upcoming capacity to determine how much work to forecast.
Step 1: Calculate Normalized Velocity
Start with the team's average velocity over the past three Sprints. Then adjust for any changes in team capacity.
Example: If a team of five completes 50 points in a Sprint where one person was fully absent, that represents 80% capacity. Dividing 50 by 0.8 gives a normalized velocity of 60 points — what the team would likely complete at full capacity.
This creates a consistent baseline.
Step 2: Determine Upcoming Capacity
Next, estimate how much of the team will be available in the upcoming Sprint. Focus on meaningful absences, not people stepping away for lunch or a meeting.
Example: If one team member is out for one day in a one-week Sprint, capacity is approximately 96%.
Avoid over-adjusting for small fluctuations, as minor variations tend to average out over time.
Step 3: Calculate Targeted Points
Multiply normalized velocity by the upcoming capacity:
- Targeted points = normalized velocity × capacity
Example: 60 points × 96% = ~58 points.
This is the amount of work the team should plan to complete in the Sprint.
Factoring in Interruptions
If the team uses an Interrupt Buffer, it must be accounted for before finalizing the Sprint Backlog.
Example:
- Targeted points: 58
- Interrupt buffer: 10
The team should pull 48 points of planned work, reserving the remaining capacity for unplanned items. This ensures the Sprint remains realistic and the Sprint Goal protected.
Common Mistakes
- Using a single Sprint as a baseline. One Sprint is not a reliable sample. Use a rolling average.
- Skipping normalization when team size changes. Raw velocity without adjustment produces misleading targets.
- Over-correcting for minor capacity changes. Small fluctuations do not require precision adjustments.
- Ignoring interrupt volume. Failing to account for interruptions leads to overcommitment.
Key Takeaways
- Yesterday's Weather uses actual delivery data to guide Sprint commitments
- It is a Scrum Inc. pattern, not a core Scrum requirement
- Normalized velocity creates a consistent baseline
- Capacity accounts for known availability changes
- Targeted points = normalized velocity × capacity
- Interrupt Buffers should be factored in before finalizing the Sprint Backlog