Scrum Guide: What is the relationship between the sprint goal and the order of the product backlog?
In Scrum, the product backlog is ordered so that the items at the top are those to be included in the next few sprints.
During sprint planning, the product owner specifies a business objective and the team transformes it to a Sprint Goal and selects the necessary items from the product backlog to achieve it.
Therefore, at worst, the order of the product backlog is irrelevant.
However, in his oown interest the Product Owner should ensures that the items necessary for the next business objective are at the top of the backlog and have been refined. In this respect, there is no contradiction.
Wouldn't it be more transparent, though, if the business objectives were listed directly in the product backlog as Product Backlog Items (PBIs) and ordered? The previous BPIs would then be details of these business objectives.
Stakeholders looking at the backlog are likely to be more interested in the business objectives than in how they are achieved. This would also make it clearer for the team which business objectives to expect for the next sprints.
These business objectives could then be refined and, in best case, adjusted before sprint planning to serve as sprint goals.
Alongside these clear business objectives, other topics such as technical debt and bug fixes would also need to be included in the backlog. However, these are not an end in themselves either, as they must have business value, addressing factors such as the ability to innovate, time to market and non-functional requirements.
I like the idea of having only one sprint goal and, if possible, including other items in the sprint. But why not include the business objectives directly in the backlog instead of tempting the product owner to maintain a separate, ordered list of business objectives in parallel?
Presumably, this approach does not contradict the Scrum Guide. But are there situations in which it would not be sensible to act in this way?
When business objectives are genuinely clear, you can expect less of an innovation context and perhaps less of a need for Scrum in the first place. Also, bear in mind the items at the top of a Product Backlog are not those to be included in the next few Sprints. That won't be decided until Sprint Planning. What they do is to feed the conversation in Sprint Planning about what a valuable and meaningful Sprint Goal ought to be. That is their relevance.
Ultimately the Product Owner can order and organize the Product Backlog however they see fit. If they wish to arrange it in terms of candidate future Sprints, or even releases, then that is entirely up to them.
Thanks, Ian.
You're right that the items at the top of the list don't have to be included in the next sprint – they're just the most highly anticipated ones.
However, I don't understand your point about innovation. After each sprint, we review what we've learned and adjust the backlog, as well as any anticipated business objectives.
What's the difference between a backlog item and a business objective? In my opinion, every PBI should have a business objective. Furthermore, it should be a business objective and therefore able to serve as a potential sprint goal.
A Sprint Goal should make the selection of work coherent. It ought to address or mitigate a signifcant risk or uncertainty in a complex challenge, hence innovation. It thereby makes the Sprint Backlog more than just the sum of its parts, and gives the Developers a reason to collaborate at all. There wouldn't be much coherence if the Sprint Goal aligned to just one Product Backlog item.
I don't believe you will be violating Scrum principles or the Scrum Guide by including business objectives in the Product Backlog. The Scrum Guide does not prescribe the format of backlog items, for example the User Story format is not mandated. (Also compare to the WBS in predictive PM, a comparable document to the backlog in Agile. It does not generally include business objectives, but are formed from the business objectives.)
One way to do what you suggest is to incorporate business objectives at the Epic level in the backlog, or even aligned with the Product Goal, and both are sometimes done. (In Scrum a product has only one active goal at a time, but product goals can switch over time.)
The key is that it makes sense to the Product Owner and the Scrum Team, and that it supports clarity rather than confusion. Do you need a clear distinction between the business objective, product goal, and product backlog items, or can you substitute the business objective for the product goal or an Epic in the backlog?