What Scrum Master should do if client comes with big CR ( Change Request ) requirement and your team already allocated and packed with existing work?
What Scrum Master should do if client comes with big CR ( Change Request ) requirement and your team already allocated and packed with existing work?
@SUMIT AGRAWAL, Should the team be allocating work to 100% capacity? Consider who should ideally channel the work and negotiate with clients as far as the work the Development Team does, Scrum Master or Product Owner? Is the work in the existing Sprint for the same client?
On a Scrum Team, the Product Owner is responsible for managing the Product Backlog, including ensuring that the Product Backlog Items are appropriately ordered, the Product Backlog is transparent to all stakeholders, and the Development Team understands the Product Backlog Items to the appropriate level of detail. Considering this, the responsibility to review and understand this change request falls to the Product Owner, since it will have an impact on the Product Backlog. The Scrum Master does provide some services to the Product Owner, such as finding techniques to effectively manage the Product Backlog and understanding empirical product planning. The Scrum Master also provides services to other stakeholders in the form of understanding Agile Software Development, Scrum, and empirical product development.
Given this, why would the Scrum Master be involved? Has the Scrum Master been engaged by the Product Owner to help in some way with Product Backlog management? Is this request an impediment in some way to the Development Team? Are their opportunities to help stakeholders with understanding and using Agile Software Development and Scrum?
I'm also curious as to why the team is "packed with existing work". If you are planning and allocating a team at capacity, how is this impacting the team's ability to adapt to changes that may arise during the course of the Sprint or even as a result of feedback obtained at the Sprint Review? Does this conflict with the ability of the team to follow through on any of the Agile or Scrum principles or values?
What Scrum Master should do if client comes with big CR ( Change Request ) requirement and your team already allocated and packed with existing work?
What does your PO has to say on the priority of this new CR ?
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
I quoted the Agile Manifesto above. Which of these do you reckon apply to your situation and how do you think this might help the Scrum Master in coaching the team and organisation?
Is the team making the consequences of accepting this new change request transparent to the Product Owner, Client, etc?
If they're already at full capacity, adding more work in progress without finishing anything will slow them down even more.You're likely to have multiple client's who aren't getting what they want in that case. If the team chooses to accept this change request into the Sprint then everyone needs to understand what work they're saying no to in order to accommodate this.
@Steve - "Is the work in the existing Sprint for the same client?" - Yes
@Thomas - "You mentioned that the responsibility to review and understand this change request falls to the Product Owner". Agree, but as a Scrum Master do I need to play any role here?
@Tony - "If the team chooses to accept this change request into the Sprint then everyone needs to understand what work they're saying no to in order to accommodate this. " I agree with you on this, but Change Request is not limited to one Sprint.
One point I want to highlight here, the current work which team is doing is started from scratch / with no past work done.
So in that case can we completely stop working on existing items to accommodate new big Change Request?
If the Product Owner is okay with all of the waste created by completely stopping the current work in progress in order to focus on a new Change Request then I'd say yes it can be stopped.
And suppose this is a continual pattern and the team is constantly starting work and not finishing it, what impact could that have on the team, the business, and the budget?
Another option might be to delay the Change Request while the team wraps up the in progress work so they can deliver the value to the business. I don't know your business context or the politics involved but sometimes the Product Owner may need to have a tough conversation with a stakeholder to show them the consequences of interrupting all of the current work in progress for a new change request.
Sometimes this transparency can result in 'ah ha' moments for stakeholders if they can see the impact of their requests.
Principle 2 in the Manifesto states: "Welcome changing requirements even late in development. Agile processes harness change for the customer's competitive advantage."
Given that, what would be the coaching response that you would advise the team?
Also, Scrum does not hinder us to change/adapt the Sprint backlog according to new information, but it does guide us to be cautious on endangering our Sprint Goal.
Other questions to consider and check with the Scrum team would be: "Would having this huge CR endanger our current Sprint goal? Do we really really need to work on it this moment, or would it be better of hold off on this until next Sprint? Is it that valuable to consider cancelling a Sprint and pivoting to this CR?"
One point I want to highlight here, the current work which team is doing is started from scratch / with no past work done.
So in that case can we completely stop working on existing items to accommodate new big Change Request?
Do you think the Scrum Team, and the client, are making the best use of the opportunity to apply validated learning?
Normally if the new scope is way different or extremely high priority, product owner can cancel the current sprint. This means, no more work done in current sprint. Go to retrospective and then planning for new sprint.
This should not be a norm, and to ensure it is not, this information should be made clear to every stakeholder. This should be a really big red flag, and be treated as such. In case of support projects, we used to do "Root cause analysis" for big issues. This is one of those cases. Clearly something went seriously wrong that we reached this stage. Do ensure that client understands the same. And ensure that product owner grooms product backlog more frequently to save on change requests.
Change request in the middle of Sprint can make sense if it's agreed and justified by the Scrum team. If the team doesn't feel comfortable of taking over the change in the middle of the Sprint, it needs to wait in the Product Backlog until the next Sprint.
My take is that :
As a ScrumMaster, he/she can facilitate to help the team and PO to see if the CR still aligns to the sprint goal. Also, he/she can assist with the team to: (1) assess the impact of working on this CR and (2) make plan to reduce the impact.
As for the PO, i do agree with Garg that the PO should highlight to the stakeholders of the consequences and whether it is necessary to extend the sprints or reduce some of the product backlogs that are less important.
Everyone replying, including me, agree on a couple of things (I'm paraphrasing a bit).
- Product Owner should be managing the impact of the Change Request to the work that exists in the Product Backlog in order to maximize the work being done by the Development Team.
- Scrum Master's role is to help the Product Owner and Development Team in any way that is requested but it is not your duty to do anything specific as you should respect the individual roles to do their best work.
- Why is a "team already allocated and packed with existing work"? The way you refer to that makes it seem to me that you have already planned out multiple sprints in advance to full capacity of the team.
...but Change Request is not limited to one Sprint.
Why would this be considered any differently than any other feedback provided by stakeholders, especially given the expected large impact to the Product Backlog? The intent of Scrum is to do incremental deliveries in order to gain feedback and adapt the next/future iterations based on that feedback. Unless this Change Request completely invalidates everything done to date, I would recommend finishing the current Sprint while the Product Owner takes the time to discuss the request with the customer and incorporate the new requirements into the Product Backlog. I would expect that some time will be needed to refine a portion of the changes before work can be done.