Sprint Goal & Modification/Negotiation of Sprint Backlog
I have a couple of questions about the principles of Scrum with regards to the Sprint Goal and the modification of the Sprint Backlog.
1. The definition of a 'Sprint Goal' seems to imply that the PBIs that were selected are all related in some way. That way, it is easy to frame a Sprint Goal that extracts the essence of the User Stories that were selected for the Sprint and craft a goal around them. However, isn't that unrealistic? Isn't it more likely that the highest priority PBIs are all from different modules/topics/subject areas, so crafting a unified Sprint Goal around them is difficult? For example, if the product was an eCommerce site, the Product Manager may have the following PBIs at the top: Implement searching / filtering of catalog items, Send order confirmation email to customer, Run credit card authorization. If the development team estimates these stories and finds that they can complete all of them in the next Sprint, they go into the Sprint Backlog but it's difficult to compose a Sprint Goal around these three items. So, in such a case, should the Product Manager keep this in mind while ordering items in the Product Backlog to ensure that related items get grouped together and hence increase the chance of them being together in a Sprint? Or, is it OK to craft a Sprint Goal that just summarizes all the stories being done in the Sprint? In the example above, it could be something like 'Allow user to search/filter, use a credit card and receive a confirmation email'
2. In the Spring Planning meeting, tasks are estimated only for the first 2-3 days of the Sprint and further task breakdown / estimation happens while the Sprint is in progress. Assume that the team finds out that they have overlooked a key factor in their estimate for one of the Sprint Backlog items and realize that they will not be able to complete it in the current Sprint. The Scrum Guide says that the Development Team can renegotiate the selected PBIs with the Product Owner. My question is: do they have to do it without compromising / changing the Sprint Goal? If so, isn't that a bit difficult / unreasonable to enforce? Going back to my previous question, what happens if the next several PBIs at the top of the Product Backlog are unrelated to the current Sprint Goal? Should the Product Owner select a lower priority PBI to include in the Sprint Backlog in order to keep the Sprint Goal unchanged?
> Isn't it more likely that the highest priority PBIs are all from different modules/
> topics/subject areas, so crafting a unified Sprint Goal around them is difficult?
Scrum is optimized for the delivery of complex products where scope is unclear and risks are high. The purpose of framing a Sprint Goal is to allow a significant risk to be addressed. A Sprint Backlog is a forecast of the work that will need to be done in order to mitigate that risk.
The harder it is to identify significant risks, the harder it will be to frame a Sprint Goal.
> should the Product Manager keep this in mind while ordering items in
> the Product Backlog to ensure that related items get grouped together
> and hence increase the chance of them being together in a Sprint?
Yes, bearing in mind that this is the Product Owner's opportunity to address a risk (such as the delivery of a complex feature) which he or she considers to be significant. For example, e PO may group items together which would constitute an MVP.
> Or, is it OK to craft a Sprint Goal that just summarizes all the stories being done in the Sprint?
No. In that situation a Sprint Goal would add no value, and there would be little point in sprinting or in having a separate Sprint Backlog.
> The Scrum Guide says that the Development Team can renegotiate the selected
> PBIs with the Product Owner. My question is: do they have to do it without
> compromising / changing the Sprint Goal?
Yes, that's right
> If so, isn't that a bit difficult / unreasonable to enforce? Going back to my previous
> question, what happens if the next several PBIs at the top of the Product Backlog
> are unrelated to the current Sprint Goal? Should the Product Owner select a lower
> priority PBI to include in the Sprint Backlog in order to keep the Sprint Goal unchanged?
If the Sprint Goal is at risk, then the Sprint Backlog should be revised to make a more viable forecast of work. The Development Team may add or remove work items which increase the chances of the goal being met. Work added to the Sprint Backlog in order to preserve the Sprint Goal does not necessarily have to come from the Product Backlog. The Development Team are free to revise the Sprint Backlog as they see fit in order to better meet the Goal to which they have committed, although they should collaborate with the Product Owner when doing so if any Product Backlog Items are affected. The Product Owner does not necessarily have to select any new work from the Product Backlog at all.