Skip to main content

The difference between the ‘forecast’ and the ‘Sprint Backlog’ in Scrum

August 17, 2018

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).

wooden brown tiles with letters spelling 'forecast'

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)

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!


What did you think about this post?

Comments (10)


Filippo Erik Negroni
07:43 pm August 17, 2018

Although I like how you are trying to differentiate the two, I really do think the term forecast was used just to convey the information that what the backlog looks like today might change tomorrow, and not completing all the items in the backlog has nothing to do with success or failure.
Originally instead of Forecast the Scrum Guide used the term commitment; that term was revised to forecast (see the Scrum Guide revision history https://www.scrumguides.org...


Sam
06:12 am August 19, 2018

What is the value of the forecast when Sprint Goal and the backlog are sufficient?


Filippo Erik Negroni
01:02 pm August 19, 2018

What I know is that it is very important to highlight to Product Owner and Stakeholders that the Sprint Backlog is only a forecast, not a commitment. The team are committed to the Goal, not the backlog.


Sam
06:10 pm August 19, 2018

Yep - I share that understanding- but got confused with the “forecast” shown as something different from the “Sprint Backlog” in the above blog.


Filippo Erik Negroni
08:26 pm August 19, 2018

Same here. I think the article is over complicating things


Zoran Vujkov
01:18 pm September 3, 2018

I agree with this that the article is over complicating things. Scrum guide is clear enough.


Alan Larimer
03:37 pm September 3, 2018

If one needs to highlight the difference between a forecast and a commitment (especially to the Product Owner) then education is needed; the pillar of Transparency has not been achieved.


Alan Larimer
04:01 pm September 3, 2018

As already noted, the term "forecast" was a deliberate change made to move away from the Taylor mindset of creating a manufacturing contract for the Sprint, moving away from output (completing all planned Product Backlog Items) and toward outcomes (achieving the value of the Sprint Goal).
The Sprint Backlog belongs to the Development Team. It can, and probably should, be made available in the name of Transparency. However it often provides little value to anyone outside the Development Team, beyond the identification of forecast Product Backlog Items. It should not be used as a measurement, i.e. how accurate of a plan was developed or how well a plan was followed (fourth Manifesto value). The results of the effort would then be discussed during the Sprint Review, including any forecast Product Backlog Items that were not completed.

ASIDE: Is the Scum(dot)org Glossary kept current with each update to The Scrum Guide?


sjoerdly
02:19 pm December 9, 2018

Thanks for your reaction! A pity I didn't see that earlier.

For me the word Forecast listed as a separate output of Sprint Planning started my quest. If you read carefully, I describe it as _part of_ the Sprint Backlog. The Sprint Backlog is a forecast of functionality AND the plan to realise it.

As said, the term forecast is used to stress the volatile nature of making future predictions. The example using the 'Forecast summary' may be helpful or not. If you don't need it by all means keep it simple.

Scrum On!


sjoerdly
02:20 pm December 9, 2018

Haha it wasn't to me. Scrum is simple to (think you) understand, hard to master! ;-)