The Scrum Glossary is an often overlooked page on Scrum.org that goes a bit deeper into terminology commonly seen in relation to Scrum. These are not always a mandatory part of doing Scrum, but are often common terms seen used by teams using the framework. I feel that the glossary takes away a lot of misconceptions that the Scrum Guide does not always take away, due to it not being Scrum and therefore not mentioned or for the sake of brevity. I am not going to explain the use of practices or parts of Scrum as these have been described over and over. These articles have a different purpose, which is to instil deeper understanding about aspects of or related to Scrum for the practitioner.
Today we are going to talk about the one of these terms in the Scrum Glossary: Forecast (of functionality), which I’ll be referring to as Forecast from this point on in the article. The glossary has the following description:
Forecast (of functionality): the selection of items from the Product Backlog a Development Team deems feasible for implementation in a Sprint.
So just to be clear here: A forecast in the sense of saying something about any further future than just the time-scope of a single Sprint is not what is being described here and it’s all about a functionality. Let’s see what they’re actually saying in the description:
the selection of items from the Product Backlog
What does this sound like? Exactly! A forecast is part of what is done in Sprint Planning. During Sprint Planning a set of Product Backlog items is selected to be pulled in the Sprint Backlog for that Sprint. This being a described part of Sprint Planning also says something about a possible antipattern: forecasts happening before Sprint Planning. If we return to the fickleness of product development that we’ve talked about before in multiple articles before this I’ve written about the Scrum Glossary you will have come to understand that emergence happens of knowledge overtime. We want to use this knowledge as late as feasibly possible to ensure we have the most up-to-date and complete knowledge possible right before using it to create our product. Because of this we want to select the items to plan during Sprint Planning that we are only then going to decide how we’ll try creating them.
a Development Team deems feasible for implementation in a Sprint.
This part screams antipattern to me from experience. I implore you, please observe your next Sprint Planning and check if your Development Team is really the ones that are deciding on the amount of items being put on the Sprint Backlog. I ask this of you, because so often I see that it’s actually different. I mentioned the verb ‘pulling’ in the previous paragraph. What I mean by using this verb is that work for the next step in the approach to our product development which is creating an Increment is pulled into that step when there’s actually capacity in time and people to do the work. Previous work has been done, and now we have room again. The people that can best decide how much room is there to do work are the ones actually doing that work. The incentive to make the amount of work feasible is also there in the accountability of the Development Team. I’ll repeat: The Development Team is accountable for creating releasable Increments of working product. To do that, they need to have a feasible and coherent amount of work per Sprint and not overload themselves. How often have you seen teams that continuously overestimate themselves during Sprint Planning, though? It might be of value to challenge them on accountability every time they decide to pick up more work than they ever managed to create in a single Sprint again.
The forecast of functionality is an interesting specific part of Sprint Planning. I see the importance in describing it, and hopefully so do you by now. Because it’s so often misunderstood by teams it might be an interesting subject to discuss in your next Sprint Retrospective. Look for ways to help the team make a better forecast and do it just-in-time during Sprint Planning to ensure we have the latest and greatest knowledge on the subject matter that the Product Backlog items relate to.
I’m really interested to hear about other experiences with the forecast done during Sprint Planning. Do you have experience to share with the rest of the community? Feel free to discuss and share in the comments below and until next time! Tomorrow we’ll talk about the term “Increment”.