Crafting the Sprint Goal
Hello Fellow Scrummers,
Is there a chicken-egg problem here? or perhaps I am missing something...
I would like to hear your thoughts.
The Scrum Guide states:
<quote>The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal.<unquote>
<quote>After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal.<unquote>
So do we have the Sprint Goal available before discussing the PBIs (otherwise how would you identify PBIs that achieve the Sprint Goal?) or do we identify PBIs to be delivered in the Sprint and then craft the Sprint Goal?
The Guide says "The entire Scrum Team collaborates on understanding the work of the Sprint". Articulating a Sprint Goal it isn't so much a chicken-and-egg problem as one of cultivating the appropriate collaborative practices.
At the end of the Sprint Planning and during the Sprint, the Scrum Team should have a shared understanding of the Sprint Goal.
However, IMO the PO has a bit more responsibilities as just to contribute to a mutual understanding: his prime responsibility is to optimize the creation of value. So before the Sprint Planning he should have prioritized the Product Backlog and has an idea what this next sprint should deliver from the business point of view. So he is forming the outline of the sprint content before the Sprint Planning.
Also note that the Sprint Goal has meaning after Sprint Planning:
- It is used to focus the Development Team during the Daily Scrum
- It is a reference when the sprint content has to be renegotiated
- It the reference to abort a sprint
- It is a token of communication to the business what the team is doing / has done during the sprint.
This has been a re-occurring questing at this forum and while writing this, I think some discussions are generated by how one interprets ‘Sprint Goal’.
1) The collection of PBI and tasks
2) The slogan we choice to represent this collection of PBI and tasks
The sprint goal is basically the "mission" of the sprint It tells which functionality and value is being delivered. To come up with the goal, the development team must have committed to the PBI it can handle in the timebox.
However, the goal is often a bit blurry in a sense that it does not elaborate on each and every detail. This way, if time gets tight, nice-to-haves and delighters can easily be dropped if not explicitly mentioned in the goal. The sprint will still accomplish the goal.
The order is: (1) select the PBI according to priority (2) come up with a goal that leaves room for interpretion
If you manage to complete all PBI in full detail, then everyone is delighted that you exceeded the goal!