Sprint Goal
Our sprint contains different PBI’s and bugs without relation; the only relation is that the items are for the next release of the same product. Do we need a Sprint Goal? Can the goal be a generic statement like “Implement some new features and fix some bugs”?
Hi Franck,
no you do not need a Sprint Goal in this case. It won't improve anything, because the sprint goal is supposed to provide guidance and focus. For this sprint you have to live with that.
What you can improve for the next sprint:
The PO should create a vision for the product.
The PO should break down this vision into goals for releases.
The PO should select PBIs for the next sprint which bring him a step in the direction of the goal for the next release.
If he does a good job, it will be possible to craft a SMART sprint goal in the next sprint planning (specific, measurable, achievable, reasonable, timely).
Best, Ludwig
> the only relation is that the items are for the next release of the same product
This suggests that there *may* be a goal for the current sprint which has simply not been articulated. It seems that there is a clear motive for this increment to be released. This implies that someone, for some reason, made the decision to aggregate these items and make them available. Presumably there are forces at work here, and the rationale behind the selection of these items might not therefore be entirely random. Perhaps promises have been made to a certain stakeholder or group of stakeholders...in which case satisfying those interests might be the goal? Try doing some root cause analysis on this and see what comes out.
Hey Franck,
since you should aim to have a running increment with specific functionalities at the end of the sprint, you need a specific sprint goal as well.
Your proposal tu use...
> a generic statement like “Implement some new features and fix some bugs”?
...won't be a good base to work agil. You need something precise to work with. As Ludwig wrote, your outcomes have to be measurable, among other things. Otherwise you won't be able to match goals and definitions of done.
Ask yourself e.g., how many features are the "some" you need to deliver at the end of the sprint?
To omit the sprint goal wouldn't be very helpful. It means you would miss out the effects of scrum. The more specific you define, the better you'll be able to identify impediments. And that means, you are able to react in a specific way.