Yesterday's Weather – How to Make the Most of Estimation

"Yesterday's Weather" is a popular Agile technique that allows teams to predict future performance. If you estimate, you definitely should use it.

"Yesterday's Weather" is a popular Agile technique that allows teams to predict future performance. This is what Jeff Sutherland, a co-creator of Scrum, says about it:

https://twitter.com/jeffsutherland/status/555416306757804032

Sounds promising, but how can it be useful for you?

Imagine that you need to plan a sprint. The stories are prioritized and estimated. The whole team sits together in the room.

You need to agree on the scope.

A product owner asks the team to implement ten tasks.
You feel that it's too much but you can't explain why.
The scrum master starts his usual speech about how challenging the scope is, and how important it is to treat challenges as opportunities.

"Does anybody have any concerns?" he asks in the end.

People stare at each other silently. No concerns. You can finally start the sprint.

Does it sound like your process? If yes, I have some good news for you – it doesn't have to be like this.


History knows everything

In order for the cow to eat less and give more milk, it needs to be fed less and milked more

– Russian saying

Imagine that this is the data about your team's past performance:

What would be a reasonable target for the next sprint? 22 story points? 20? Both look reasonable.

But how about 10? That doesn't sound right.
Maybe 42? Maybe, but why do you think you're going to double average velocity?

If you have the history of past performance, some numbers will look groundless.

Not all sprints are equal

Your performance won't be consistent from sprint to sprint. A huge factor contributing to variability is the team's capacity.

Capacity – is a number of days that people work.

If we have five days in the sprint and three developers, our capacity would be 15. If one person is out for a week – 10 person-days. If one is out for a week and someone else is out for a day, the capacity would be 9 (as in our hypothetical "new sprint"). Let's think about how we can account on it.

Only three sprints (2nd, 4th and 6th) were full (3 * 5 working days, assuming that a sprint lasts for a week).
What would we achieve if we always had three people? Just hypothetically.

Well, it's easy to calculate, we need to calculate the velocity of one person-day (Velocity / Capacity) and multiply it by 15, which is our ideal capacity:


The right target

Now you know that your team is capable of doing 22 – 30 story points per sprint. But what should be your target for the next one?

My advice won't surprise you – I'd recommend to pick an average. In our example the average theoretical velocity is 24 ((30 + 25 + 24 + 22 + 23 + 22) / 6).

Now we need to normalize it on our planned capacity (24 / 15 * 9) to see that the realistic goal for our team is 14 story points:

It makes sense to take only the recent history because the team's velocity changes over time. 10-12 sprints would be optimal.


All together in one spreadsheet

Luckily, you don't need to do all these calculations yourself. There are many implementations of it, but the most popular one is the spreadsheet made by Scrum Inc.

Even though it's enough to start, you may want to adjust it: add more dates, assign different weights to different people and so on. It shouldn't be difficult since it's just a spreadsheet, but I will cover the most common changes in one of my next articles.