Skip to content

Yesterday’s Weather pattern

    Does your team’s Sprint Burndown look like this?

    Sprint burndown

    Does every Sprint end with a bunch of work still unfinished?

    Do you get a sense that you are over-committing yourself but don’t have a clear idea of how to manage the situation?

    You are not alone.

    The Yesterday’s Weather pattern

    The Yesterday’s Weather pattern may help. Basically, you look at past performance and use that as a baseline to establish capacity for the next Sprint. In this way, the amount of work committed in a Sprint Backlog is no longer based on wishful thinking, the boss’s pressure, or a “stretch goal” you are trying to set for your team.

    Now the plan for the Sprint becomes achievable, because it’s based on realistic measurements of past performance. How much work have we demonstrated that we can accomplish in prior Sprints? Some teams call it Velocity and measure it in story points. Same thing. That becomes the upper measure of capacity for your next Sprint.

    Note the keyword here: upper. This should be your maximum capacity. Don’t go above it, otherwise you set yourself in over-commitment territory from the start. Instead, an argument can be made about going lower than the max. That is, setting a buffer.

    When you look at past performance you measure the amount of work completed in prior Sprints. Typically, you may want to look at the last 3 to 5 Sprints, and then take the average. If you are using story points for your estimates, you add up the story points for all the work completed in a Sprint, and that gives you the Velocity for that Sprint. Take the average for the last 3 to 5 Sprints, and you have the Average Velocity for your team. Again, this defines the upper limit of your capacity for the next Sprint.

    The key here is to establish reasonable commitments for the Sprint that are based on available capacity for the team. Whether you use story points, no-estimates, or any other practices, try to gauge the amount of work you can reasonably complete in a Sprint and set that as your available capacity.

    When teams establish commitments that are too large for them, they over-commit. That means that they set the wrong expectations with their stakeholders, that plans becomes unreliable, and that any promised date is not achievable. Over-commitment also puts undue pressure on the team often forcing the team to multitask, trying to finish everything within the Sprint. Unfortunately, neither pressure nor multitasking are good practice to help the team improve performance.

    If you want to help your team improve performance, limit the amount of work they take on in a Sprint. Remove the pressure and the “stretch goals”. Establish reasonable commitments based on available capacity. Support your team in delivering on their commitment. They can always do more work if they achieve the Sprint Goal early. In fact, there is no limit to how much a team can complete in a Sprint. But this is only true if the Sprint Backlog represents a reasonable commitment that the team knows it can complete 100% by the end of the Sprint. Let the team finish the work, and then take on any additional tasks or “stretch goals”.

    The Yesterday’s Weather pattern is one of many patterns that successful Scrum teams have demonstrated help them improve their performance.

    Real-life story: from 27 to 33 points in 2 Sprints

    I would like to share a story about how using the Yesterday’s Weather Pattern can help a team improve its performance. This is a real-life story of a team that was already on Sprint 23 or 24. They had been together for almost a year working on this project.

    When I joined the team, I participated at Sprint Planning. The conversation pretty much went like this: The Product Owner came in and said, “Hey team, these are my priorities. I would like for you to do these 57 points, this Sprint.” The Developers looked at each other, and then said, “Okay”. After that, Sprint Planning was pretty much done.

    Later in the day, I went into the system looking at metrics for past performance. I pulled the Sprint burndown charts from Jira. As long as you update the data throughout the Sprint, Jira can generate a Sprint burndown automatically. I went in and looked at the Sprint burndowns for the past Sprints and I noticed that this team never delivered more than 27 points. In fact, 27 was the max they ever delivered.

    Now, I was baffled because at Sprint Planning, they just committed themselves to 57 points. That was more than twice over commitment. It didn’t make sense to me.

    So, I reached out to the Developers and I said, “Can you please explain to me what are you doing?” They said, “Well, the Product Owner is our boss.”

    I understood there was no psychological safety and there was no way for the Developers to really push back based on their available capacity. So, I went to the Product Owner and I said, “Look, Product Owner, the team never did more than 27 points in a Sprint. Why did you give them 57? That’s more than twice over commitment. It doesn’t make sense to me.”

    The Product Owner says something like this, “First of all, this is my team. I decide how much work they do. Second, if I give them less work, they are going to slack and give me even less. In fact, I’m thinking I’m going to give them even more work next time.”

    I said, “Wait, okay, but look, there is a reason why you called me to coach this team and help you improve. What you’re doing doesn’t really help, does it?”

    After a little bit of negotiation, he finally agreed to run the next Sprint at a maximum of 27. Now you get it: 27 was not ideal yet because we did not have a buffer on capacity. But still, 27 was much lower than 57 and more closely related to what had been the performance of this team historically.

    We ran that Sprint of 27 points, and at the end of the Sprint, the team delivered 30 points. You may say, “Okay, lucky event, one shot,” these kind of things. I get it.

    So, we decided to run a second Sprint, also at 27 points of capacity, and the team delivered 33 points. Now you see, in two Sprints, the team was able to go from 27 to 33 points, and that is a 20% increase in performance. Nothing else changed in the team, not the way they worked, not the systems, or the resources. Nothing changed except removing the over commitment.

    We removed the pressure by committing to a reasonable capacity that was based on past performance. When the team was able to commit to their reasonable capacity, they were actually able to deliver everything they had scheduled in the Sprint Backlog and more. And over a few more Sprints, the team was able to increase its velocity further to 40 points.

    That’s how you help your team improve. That’s the pattern of Yesterday’s Weather. Looking at past performance, to give you a sense of what is the available capacity that the team should really plan for at Sprint Planning.