There is a difference between the forecast and the Sprint Backlog in Scrum. Exactly what this difference is, has eluded me for some time, and it may very well be unclear to you too. The difference may seem subtle, but can have real practical benefits as you will learn below. Warning: this article can and should be considered in the 'Scrum Nerdery category. For some, the dissection of words used in the Scrum Guide may not seem necessary, for others it can provide some additional insight.
The way I used to look at forecast & Sprint Goal
In the slides of the Scrum courses I teach, the results of the Sprint Planning are listed as: Sprint Goal; forecast; Sprint Backlog. Ever since the PSPO TTT I’ve had the unsettling feeling that I should have a better grasp on the reason for separately listing the words forecast and Sprint Backlog there. In my mind they were always just different words for the same thing. To me, both were different words to describe the current ‘best’ plan that the Development Team has for achieving the Sprint Goal. Creating transparency on the forecasted functionality as a list of Product Backlog Items (PBI’s). These are most often directly pulled from the top of the Product Backlog.
In the Scrum Guide, the word forecast is used in the first sentence of the Sprint Planning chapter:
The Development Team works to forecast the functionality that will be developed during the Sprint.
It is also mentioned when describing the Sprint Backlog:
The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.
This does not clarify a lot regarding the relation of the Sprint Backlog and the Forecast. At least it did not for me, until now.
The moment of insight; reading the Scrum.org Glossary
So what happened? Today I was reading the Scrum Glossary and through its descriptions the distinction finally clicked. The Forecast (emphasis mine):
Forecast (of functionality): the selection of items from the Product Backlog a Development Team deems feasible for implementation in a Sprint.
And the Sprint Backlog (emphasis mine):
Sprint Backlog: an overview of the development work to realize a Sprint’s goal, typically a forecast of functionality and the work needed to deliver that functionality. Managed by the Development Team.
So here we have it. The forecast is part of the Sprint Backlog. The Sprint Backlog consists of the forecast (of functionality) plus the work needed to deliver that functionality. The forecast is made transparent through the Product Backlog Items selected during Sprint Planning by the Development Team. The Sprint Backlog expands this by additionally making transparent the work that is expected to turn these PBI’s into a ‘Done’ Increment (releasable & usable).
Forecast by Nick Youngson CC BY-SA 3.0
A practical application using the difference between forecast & Sprint Goal
As an added bonus, we could use the forecast explicitly as a summary of the complete set of functionality that is believed to fulfill or reach the Sprint Goal. This means we have a Sprint Goal, plus a forecast summary to describe the what and how of the current Sprint. The Sprint Backlog then describes the plan and details the changes to the Increment that are thought to be needed to reach the Sprint Goal and realize the forecast.
An example:
- Sprint Goal: Drastically improve accessibility of Shopping Cart for the visually impaired
- Forecast summary: Changing visuals to be color-blind compatible AND HTML structure to be screen reader proof and support keyboard navigation.
- Sprint Backlog:
- Update button elements to be colorblind compatible (either by better images or changing to pure css)
- research best accessible option that is still pretty for non-impaired users
- Optionally create new images
- Update code (and/or images)
- Run accessibility tests on button elements
- Validate other DoD items
- Refactor HTML to latest standards (which better support accessibility out of the box)
- X
- Y
- Z
- Add ARIA tags to HTML where needed
- etc
- Improve HTML structure to support logical tab order
- Add labeling to inputs to support screen readers
- Support text zooming better (currently some layout breaks when using browser zoom)
- Update button elements to be colorblind compatible (either by better images or changing to pure css)
I hope this helps clarify some potential confusion and maybe the use of an explicit forecast even helps to better communicate with Stakeholders about what to expect in a Sprint Review.
Is this useful, or do you have more questions about this topic? I’d love to hear your comments below!