Handling Scope creep in the Sprint
22nd Feb, 2020
How to handle scope creep in a Sprint?
On 15-Feb-2020, in Agility Thinking WhatsApp groups, there was a discussion on this topic. Many of the practicing Agilists from the Agility Thinking group participated in the discussion in WhatsApp and below are some of them.
Completely depends on a teams capacity and priority of user stories in the sprint backlog! If there is no capacity and all items already scoped are priority, SM needs to talk to the product owner and convey it cannot ve done! If the new ones are more priority accordingly the lower priority ones are to be moved out of the board!
Initially evaluate the scope creep to understand the impact of its delivery and the cost involved in implementation along with other parameters like time and effort
If there are benefits involved and the client is willing to negotiate with the delivery timeline with the extra costs then communicate the same with all the relevant stakeholders. There should be a clear understanding of the requirements with no room for any ambiguity within the team and the clients. Analyze which items can be de-scoped to accommodate the new requests to deliver a testable product. Discuss the cause of the scope creep in the retrospective meetings and arrive upon plans for improvement.
Whenever new requirement will come after the sprint starts below steps will help to handle the changes:
1. Discussed the priority of the change with PO
2. Discussed (GROOM) the requirement with team with the help of PO
3. Understand the effort required to complete those requirements, identify dependency & everything.
4. Ask the team if they can achieve this change within the remaining days of the sprint.
5. If they say yes but need to remove something out from already planned work.
6. Ask PO that team can achieve this in the current sprint only if we take out something which was already planned. So as per the priority tell which user story to take out. The basis on this discussion u as SM can handle the scope creep.
Scope creep is a remnant of the waterfall model of thinking, wherein software development is driven by a process, sticking to the SRS documentation, as per scope defined in the contract and moving according to a stated plan. So scope creep cannot be handled in Sprints. Yes, we are agile and we welcome change even at the last moment. We just need to understand if this new requirement is worth changing the previous plan and formulating a new plan. Or is it better to stick to the current plan and make the next plan incorporating the new insights?
Lots of things to consider
- Is there a time-critical to it? If GDPR is approaching and your product handles customer data it needs to be done before the law kicks in.
- Is there a severity criticality to it? If your payments integration is charging double the amount, we first need to get that sorted out. Before more and more customers start clamoring for refunds.
- Is there a time dimension involved? We had promised a feature to customer last month and somehow it's still in the backlog. Especially in a B2B scenario, it would be important to adhere to dates because the customer would have lined up other business activities like marketing based on the previously agreed-upon dates.
- How important is the new requirement for our use case? Maybe we are Facebook and we need to stop all else that we are doing and just do social networking. If it is a product defining/redefining/business pivot decision from which the new requirement is driven, it makes sense to course-correct immediately.
- What are the business benefits of doing it immediately? What will I need to postpone doing if I do this immediately? What is the business impact of that postponement? Do the business benefits of doing the change immediately vs what we lose by postponement work out in our favor?
- Is the feature in the new requirement a must-have for our product that we missed? Are we working on some nice-to-haves that we can look into later? Is the new requirement a mind-boggling feature that we should prioritize over nice-to-haves?
- Is it even possible to be picked in this Sprint? Does the new requirement need a lengthy setup that it will take beyond this Sprint?
I am also wary of adding members to the development team to get more work done. We literally treat our developers like cattle "Hurr, Hutt". As if they have no thoughts, no freedom. We just "hurr, Hutt" them as it pleases. It just doesn't work. A new joiner will take time to assimilate into the team. He/She will need time to understand the product architecture. By the time all that happens, the Sprint will be over. No logic at all. We treat software development as if it's similar adding one more person to man the call center to handle a spike of incoming calls. But software development is fundamentally different.
A product backlog with the correct vision ideally will not give rise to scope creep in a sprint.. (the👌🏻 vision) But creep happens ⛈ 😮💪, the dev team + PO course can correct and adapt. The scrum master helps in navigating the new course and ensures the adaptability and process.
What do teams do:
- First, ask WHY the change is really imp? Sometimes because you cannot say NO to stakeholders it does not mean u should say yes!
- Swap stories in the sprint with the creep. (Maintain the sprint happiness)- go for an ad hoc planning?
- If the change comes mid-sprint... it’s like halfway journey, scrum team to take a call if the WIP stories can be exchanged with creep! 🤪🤷♂ (this is when mostly I see devs get frustrated 😖 and the scrum master’s skills get into action)
This does not have a simple answer. When was the scope creep identified?
1. If it is at the time of sprint planning we can prioritize the same.
2. And if it is during the middle of Sprint, we need to understand the priority of the scope creep. if it is a must, then does the team have the bandwidth to take up the additional user story or not. If yes then do it else move some of the agreed user stories to the backlog at the end of the Sprint.
3. If the scope creep has a monetary impact, it needs to be taken up by moving some of the agreed user stories to the backlog.
4. If the scope creep is not a priority and more like nice to have then create a user story put it in backlog and prioritize it to be taken up in the subsequent sprint.
The objective is to deliver an incremental product that can be used by customers. If not addressing critical scope creep and delivering all user stories is delivering an increment that doesn't benefit customers than what is the use of that sprint. If the creep is monetary impact to your company or customer company than come what may they will insist on it to be delivered. If the team has bandwidth than not a problem, else you will have unfinished user stories. It will as per the normal process will be shifted back to product backlog for taking up in the next sprint. But you cannot say sprint plan is done and scope creep will not be handled.
- Identify the reason for scope creep and Its importance.
- Chart solutions
- Continue with current work.
- Backlog current work and start with scope creep items.
- Find a balance b/w current work items and scope creep.
- Run Intended and Unintended causes for all the three options a,b and c to identify the benefits.
- Showcase the benefits.
Weigh them against each other to get the best solution. It may lead to a tailored or hybrid solution for all the problems.