Hi Maarten,

I found this article very interesting. I like how you've elevated the Sprint Goal and tried to make it look more an overarching objective that the team is working towards.

However, the Sprint Goal is only constructed during Sprint Planning, before then the only relevant thing that exists is the Product Backlog, ordered by the PO with most valuable items on top. So the PO arrives at planning with a list of work items that are most important to build, and the team draws in the items from the Product Backlog, and finally tries to formulate a Sprint Goal around them. This seems backwards to me.

From the perspective that the Sprint Goal should be the overarching objective, i.e. that it is the most important thing, surely this should be defined *first* and then suitable work items that fall within that goal are selected, rather than the other way around? If this were the case, the Sprint Goal would more like an Epic or a theme that is defined and prioritized ahead of time, and individual work items would be more like tasks that slot in underneath it.

See, I think there is a contradiction between commiting to a Sprint Goal vs a list of Product Backlog items. I think we can only try to commit to one and not the other, because it's too hard to juggle committing to both with the same level of priority. Ultimately, one has to be subbordinate to the other and allowed to adjust. If that is the selected Product Backlog items, this suggests that the way in which we conducted the Sprint Planning was wrong to begin with.

I'm keen to hear your thoughts on this.