It is clear that in Sprint Planning the Product Owner has to be present. However, since the Development Team is responsible for current sprint work, does the PO need to attend Replanning? Although the Sprint Goal will be likely altered, only the Dev Team knows how much work they can take and therefore will modify the sprint based on their knowledge.
Add a comment
|
2 Answers
TL;DR
[S]ince the Development Team is responsible for current sprint work, does the PO need to attend Replanning? [sic]
Yes, the Product Owner needs to be present at all scoping and planning sessions.
Adjusting scope within a Sprint is possible, but only with the full participation of the Product Owner. Changes to the Sprint Goal should trigger an Early Termination of the current Sprint and a return to Sprint Planning.
How to Change Scope and Sprint Goals in Scrum
There is no such ceremony as "Sprint Replanning." It sounds like you've created a special ceremony for cutting scope from the current Sprint, but Scrum already supports this process within the standard framework.
Cutting scope within a Sprint is certainly possible, but:
- The Product Owner must be involved. No changes in planned scope can be made without the involvement of the Product Owner.
- Changes to the Sprint Goal may only be made with the full agreement of the Product Owner. The Sprint Goal represents a planned increment of value, so the Development Team can't change the Sprint Goal unilaterally.
- A change in the Sprint Goal should trigger an Early Termination by the Product Owner and a return to Sprint Planning. If the central goal of a Sprint is invalidated for some reason, it needs to be scrapped and re-planned by the entire Scrum Team (including the Product Owner) after a brief Sprint Retrospective to identify what went wrong.
In short, the Development Team may not cut scope or change goals without the active participation of the Product Owner. Doing so undermines the core responsibilities of the Product Owner role, and removes essential project controls from the framework.
answered Jan 20, 2016 at 12:56
-
This feels very trigger happy to me. Yes, the PO should be informed when scope decreases and asked what can drop from the sprint, but for it to trigger an early termination is very process heavy. Developers get poached all the time and stories occasionally turn out to be bigger than thought. It is less disruptive to meet and discuss the decrease in scope without all the ceremony. Besides, there is not reason why the decrease in scope couldn't be a topic in the already planned retrospective.– zeepleCommented Jan 20, 2016 at 15:56
-
The scrum guide agrees with #2 and #3 but not #1. The purpose of the Sprint Goal is to slow the Development Team to change scope without PO intervention. Commented Jan 21, 2016 at 1:50
-
@MrHinsh That is incorrect. The Sprint Goal is meant to guide implementation details, not to allow the Development Team to change scope unilaterally. In fact, the Scrum Guide explicitly says: "No changes are made that would endanger the Sprint Goal" (The Scrum Guide, 2013; p. 7) defined during Sprint Planning for the current increment. If you are still unclear on this, I would strongly recommend that you open a new question so that you can receive more thorough answers on this related topic.– Todd A. Jacobs ♦Commented Jan 21, 2016 at 2:15
-
1Well said @CodeGnome. This is exactly right and demonstrates the flexibility of the Scrum Framework to support the principle of agility that states, "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." Commented Jan 21, 2016 at 20:53
Great question. In my experience anytime you are adjusting either the sprint scope or the sprint goal the product owner needs to be involved. I think of the Scrum team as the "delivery team" and the delivery team delivers whatever the product owner has determined to be the highest value work. So as soon as you say adjusting the sprint goal, I think, "okay, the product owner set the last sprint goal, we should let her know that we cannot achieve it and need to replan." Also, even if the sprint goal is intact, and really you just have a decrease in capacity (a developer was poached, maybe) the product owner should get to determine which work item can drop off the sprint. Make sense?
