The Scrum Sprint Forecast as an Expectation
There is no improvement without learning
According to Steven Spear, there is no improvement without learning. There is no learning without surprises. There are no surprises without setting expectations. Specifically challenging expectations that will be missed occasionally. See a quote from one of his Harvard Business Review articles about how Toyota really learns:
We argued that Toyota’s much-noted commitment to standardization is not for the purpose of control or even for capturing a best practice, per se. Rather, standardization—or more precisely, the explicit specification of how work is going to be done before it is performed—is coupled with testing work as it is being done. The end result is that gaps between what is expected and what actually occurs become immediately evident. Not only are problems contained, prevented from propagating and compromising someone else’s work, but the gaps between expectations and reality are investigated; a deeper understanding of the product, process, and people is gained; and that understanding is incorporated into a new specification, which becomes a temporary “best practice” until a new problem is discovered.
Expectation-driven Learning applied to Scrum
So one way to see the Sprint Forecast is as setting an expectation of how much work is going to be done before it is performed and committing to trying to work as effectively as we can to try and meet that forecast. Sometimes there will be a gap between our forecast and the real amount of work done, which is an invitation to learn about our real capabilities, our processes, and our people and drive new experiments for how to deliver at a higher level. I see this as a healthy use of commitment.
This again explains why a team that meets its forecast each and every time might be a predictable team but not necessarily a hyper-productive team and for sure not a learning team. For learning, you need to hypothesize that you can stretch yourself a little beyond your current capabilities supported by an experiment for how to achieve that stretch. But hypothesis and experiments have this nature of sometimes succeeding and sometimes failing. So you would expect to sometimes miss your forecast and have to learn something from it. Again, no learning without surprises.
Using this frame of thinking with Scrum, by the way, is similar to how Limiting WIP drives improvement in Kanban. It re-emphasizes how working in a pull system driven by commitment to either WIP Limits or Sprint Forecast are very similar concepts of constraints and expectations – explicit process policies that drive learning. This learning is not less important than the ability to predict delivery outcomes that comes together with working in this pull system.
What can we do different tomorrow morning
Scrum Team? Make sure you set a challenging sprint forecast, supported by clear hypothesis and experiments of how you will reach that forecast while still working at a sustainable pace. Commit to trying. Even more importantly commit to learning if the experiment fails. Remember this is a safe-to-fail experiment.
Manager? Give your teams permission to experiment. Expect them to experiment. Expect them to commit to trying and learning. DON’T expect them to always meet the forecast limit or you will slow down learning. Expect them not to ignore their commitments. Expect them to come to you with requests for assistance and ideas how to achieve lower WIP limits or higher sprint forecasts. Expect them to try some of those ideas on their own without any help. Finally and probably the first thing to do – Teach them that there is no hyper-productivity without improvement. There is no improvement without learning. There is no learning without surprises. And there are no surprises when there are no expectations.