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 on WhatsApp and below are some of them.

Manikandan Krishnan

Completely depends on a team's capacity and priority of user stories in the sprint backlog! If there is no capacity and all items already scoped are a priority, SM needs to talk to the product owner and convey it cannot ve did! If the new ones are more priority accordingly the lower priority ones are to be moved out of the board!

Prithvi

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 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 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.

Nikhil Sawant

Whenever a new requirement will come after the sprint starts below steps will help to handle the changes:

1. Discussed the priority of the change with the PO

2. Discussed (GROOM) the requirement with a team with the help of PO

3. Understand the effort required to complete those requirements, identify dependencies & 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 from already planned work.

6. Ask PO if the 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 of this discussion u as SM can handle the scope creep.

Rahul Baji

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 the 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 customers 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 the 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, and no freedom. We just "hurr, Hutt" them as it please. 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 to adding one more person to manage the call center to handle a spike of incoming calls. But software development is fundamentally different.

Sudarshan TS 

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 ad hoc planning?
• If the change comes mid-sprint... it’s like a 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) 

Chetan

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 is 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 then what is the use of that sprint? If the creep is the monetary impact to your company or customer company then come what may they will insist on it being delivered. If the team has bandwidth then not a problem, else you will have unfinished user stories. It will as per the normal process will be shifted back to the product backlog for taking up in the next sprint. But you cannot say the sprint plan is done and scope creep will not be handled.

Sailesh Canchi

• 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 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.

This is just a speck of knowledge on your journey to becoming an expert in the industry. If you have any doubts or require career guidance, feel free to connect with our Industry experts and trainers for 1-on-1 coaching. 

"We upskill and boost your career by providing a wide range of courses such as CSPO, CSM, ICP-ACC, etc. visit our website to learn more about all the courses we offer."