Sprint Goal

> IF we have selected a sprint backlog and have crafted the goal
> based on these selection, how does any change to functionality
> implemented not compromise the Sprint Goal?

A Sprint Backlog is a forecast of the work that will be needed to meet the Sprint Goal. Might that forecast need to be revised, based upon the turn of events during the Sprint?

Does that mean that the Dev team can actually change the sprint backlog items by adding or removing of sprint backlog items based on turn of events?

If yes, please clarify my understanding:

* The PO first comes up with his vision of what should be achieved through the upcoming sprint. This objective is at this point just a "draft" of the Sprint goal
* on discussing further within SCRUM TEAM on reviewing the PB further, more clarity emerges
* Based on the understanding of the "draft" and ensuing discussions, DT selects the PB items for sprint in agreement with PO
* Once the PB items are selected, the ST then crafts the Sprint Goal
* The DT starts the Sprint after work planned for initial few days is decomposed
* Once more clarity emerges as the Sprint progresses, it is possible that the Dev team feels that some of the Sprint Backlog items selected might not be appropriate for meeting the SG. At this point, can the Dev Team alter the Sprint back log items selected?

Extension to my previous points, is it possible to completely remove some of the existing SB items and replace them with new ones during a sprint if found to be more appropriate for meeting sprint goal?

Yes, that is correct.

Hi All

So, does that mean that since the Sprint Goal doesn't change,

1. the PB items can be changed if they are not helping to accomplish the sprint goal?
2. And then those items that will help in achieving the SG would be selected?
3. So how does this relate to re-negotiation of sprint scope?

Is this what is meant by "Flexibility" in this sentence?

Ideally the team and the PO should have the goal in mind before selecting the PBIs for the sprint, but it is an iterative process, i.e. after refining and clarifying some PBIs the goal might need to be changed as well.

The goal talks about the outcome the teams should achieve in a Sprint. The Spring backlog might change as the understanding of how to achieve this outcome grows, this is a collaborative process between the Development team and the Product owner.

Does it make sense to continue working on the Sprint backlog after the desired outcome (goal) has been achieved? Maybe, if it can achieve other significant outcomes or maybe there are more important things to do...

@Boris: Very well put. I've always found it strange that the order is First: Select PBIs and Second: Define the sprint goal, but as you say this should be an iterative process where PBIs are selected with the objective in mind. However I think this should be elaborated in the guide.

You could think of the PO (and preferably the team) as having an MVP in mind when they enter Sprint Planning. An MVP might reasonably emerge from Product Backlog refinement activities such as user story mapping. During Sprint Planning the team would craft a Sprint Goal around that MVP, although they may need to revise it in order to capture the latest understanding of value, or to plan an achievable forecast of work into the Sprint Backlog.

I have been working with my teams PBIs first/Sprint Goal second, however after making more research on Sprint Goal Setting this last few days, it does make more sense to select the Sprint Backlog based on the Sprint Goal, as Fredrik mentioned, even though it is almost a work on parallel all together.

I beg to differ a bit, if we have a pre-conceived Sprint Goal in mind and then we select the PBI's to achieve the goal, these PBI's may not be defined yet. As per the guide, generally the PBI's on top are clearer and have more details with good story points. These are the candidates for the sprint as they can be completed in one sprint term. Other PBI's which may be a candidate for the pre-conceived SG may not be fully defined yet. To get them defined first means losing time when a sprint can be performed.

I think that related PBI's from the top of the PB list should be selected and then the Sprint goal can be formulated. Of course, as and when new knowledge is gained and if there are undesirable variances, scope can be negotiated and PBI's can be added or removed to the Sprint Backlog.

I have the same question why the Sprint Goal is formulated after the PBIs are selected by DT. Would it be better if SG is formulated first based on the PO's objective that the Sprint should achieve. Afterwards, DT will have a better view on what PBI to select for the Sprint and thus, preventing wasted effort on working thru unrelated PBIs during the Sprint. Kindly advice.

Hi Hermes,

Sprint Goal gives a specific objective and direction for the DT to work on and achieve it within the duration of the sprint. Sprint goal cannot be crafted until PBIs are fully understood and accepted by DT to deliver within that Sprint.
Imagine if you decide to craft Sprint Goal first, however selecting PBIs later gives you the wrong picture what would you do?

Pankaj