Product goal and sprint goal
I've been researching product goal and sprint goal in a significant amount of detail and want to share a couple of thoughts.
Sprint planning involves devising a plan (the selected PBIs and possibly tasks) to meet the Sprint Goal. The Sprint Goal is a step toward the Product Goal. Sprint Goal is the "why," selected PBIs are the "what," and tasks or other techniques describe the "how."
Many people use Sprint Planning to pick PBIs based on the team's capacity (usually velocity) and to select them in sequence based on the Product Backlog.
It's more agile if you pick PBIs based on a proposed Sprint Goal and, once you've picked close to capacity, tweak the Sprint Goal to align with the chosen items. This is the way to allow flexibility incase the "what" needs to be adjusted.
BTW, Sprint Goal shouldn't be a restatement of the selected items, but that's a different story.
How do you know when you have a good Sprint Goal? It acts as a stepping stone toward the Product Goal.
I see quite a few people who don't even use a Sprint Goal and even fewer who use a Product Goal. Without a Product Goal, it's hard to say you have a Sprint Goal that helps you move toward a particular direction.
Do you use a Product Goal and Sprint Goal?
I like where you're going, but if I'm understanding correctly, I don't agree with what you say about picking to capacity.
Allow me to describe what I see as an effective Sprint Planning flow.
The Product Owner arrives at Sprint Planning with an idealized version of the Sprint Goal and shares it with the team, with some discussion to understand it. There may be some clarification or revision to make sure it's clear among everyone participating. From here, the team collaboratively selects Product Backlog Items that support the Sprint Goal, until they have identified all of the work believed to be necessary to achieve the Sprint Goal. Then, they check the selected work against the team's capacity. If the selected work is less than the team's forecast capacity, they are done. If the selected work exceeds the team's capacity, they need to find a way to reduce the work, either by revising the Sprint Goal, deciding that some work isn't necessary to satisfy the Goal, revising their sizing since the work was originally sized, or a combination of these.
If the work needed to achieve the Sprint Goal is less than the capacity, it's up to the team as to how to proceed. Some teams want to select more Product Backlog Items to fill to capacity. Others may select more Product Backlog Items for implementation during the Sprint.
You never need to revise the Sprint Goal to encompass selected Product Backlog Items. It's acceptable for the Sprint Goal to be accomplished with the delivery of one or two Product Backlog Items out of a long list. This helps drive home the separation between the Sprint Goal and value-oriented delivery and feature-oriented delivery (or a feature factory model).
When it comes to the "how", there is also room for variations. I'd like to see the how focus on how to achieve the Sprint Goal, so any discussions about how should focus on getting the Product Backlog Items that directly support the Sprint Goal to Done and delivered. However, if the Sprint Goal is achievable with only a sliver of the selected Product Backlog Items, the team may want to spend some time talking about how they will get the other work delivered. My preference is toward a shorter, leaner Sprint Planning and deferring more to later. This is especially helpful if there is work discovered over the course of the Sprint that must be done to achieve the Sprint Goal.
A good Sprint Goal can be any coherence, such as a feature or flow-based objective, which gives team members a reason to work together during the Sprint. This commitment makes the selection of work more than just the sum of its parts, and may allow a significant risk or uncertainty to be addressed when facing a complex challenge.
It can sometimes be helpful to ask: what is the smallest thing that can be Done at all this Sprint? In other words Sprint Planning can actually begin with a technical plan drawn from the Definition of Done, such as tasks. A Sprint Goal and forecast of PBIs may then be induced from that. This can be a really aggressive way of identifying an MVP.
Thomas - I was approaching the Sprint Planning thinking that the candidate Sprint Goal is more than can be accomplished. I agree with your point about SG not be revised to be MORE encompassing.
Ideally you wouldn't have extra PBIs selected for a sprint that don't support a Sprint Goal, otherwise the Sprint Goal and ???? is the purpose of the Sprint.
Here is my opinion.
The Sprint is a timebox where the Developers do work to improve the product. The Sprint Goal is what indicates the reason that you are undertaking work in the Sprint. The Sprint Backlog will contain Product Backlog Items that will allow the Developers to achieve the Sprint Goal. That is the short answer.
Long answer. The Sprint Backlog contains all of the work that the Developers have chosen to work on during the Sprint timebox. It should contain only enough work that can be completed during the Sprint timebox. In the selection of Product Backlog Items there will be enough items to achieve the Spring Goal. However, the entire Sprint Backlog does not have to support the Sprint Goal. If they can achieve the Sprint Goal and still be able to work on other things (i.e. technical debt, preparation of something that will be needed in the future, a prototype to prove a theory that will aid in refinement of other stories in the backlog, ...) then there is no reason that they can't include those items if they are in fact items in the Product Backlog. If not, they can use the "free time" to work on items of that nature. If there are items not related to the Sprint Goal, they can be removed or sacrificed if the team encounters unexpected issues and the Sprint Goal is at risk.
Capacity is not the gating element for Sprint Planning. The Sprint Goal is the gating element. If the Sprint Goal is found to be too ambitious, then the Scrum Team needs to discuss ways of adapting. The Developers are the ones planning the work that they will do during the Sprint timebox. It is up to them to decide what that work will be.
I have never recommended that a Development team plan a Sprint at "full capacity" no matter how you define that. I always remind them that they are planning at the point where they have the least knowledge about the work they will be undertaking. We all know that something will be discovered when work begins and the only way to plan for that is to have time to react.
However, the entire Sprint Backlog does not have to support the Sprint Goal. If they can achieve the Sprint Goal and still be able to work on other things (i.e. technical debt, preparation of something that will be needed in the future, a prototype to prove a theory that will aid in refinement of other stories in the backlog, ...) then there is no reason that they can't include those items if they are in fact items in the Product Backlog
I'd go further and suggest it might be smart to do so, because those "other things" provide contingency that can be sacrificed, if needed, so commitments can be met.
If there are items not related to the Sprint Goal, they can be removed or sacrificed if the team encounters unexpected issues and the Sprint Goal is at risk.
That's right. Failure to allow for such eventualities may result in quality being cut.