Agile 101
How to deal with Change of Requirements or Scope Creep in Agile?
Learn how to average the chage in scope and scope creep in Agile as a Scrum team
Early in my career, I knew scope creep is the death of productivity, projects and products. In my head, chasing the requirements meant something never sees the daylight. That’s how dramatic I saw this issue and how serious I was about it. From my role of guardian of the processes for the team, I was very strict about anything extra that gets added. But a decade later, I see change as progress.
Wait. What? You are coaching teams and organisations to be agile, launch better products, be on time, be predictable, and you encourage CHANGE?
I encourage the teams to learn! Give feedback! Improve every day! To challenge themselves and to change when something doesn’t work. In a structured manner.
Here are the questions I ask before accepting a change request as Agile team?
- Does it serve the Sprint Goal? The only fixed thing during the sprint is the Sprint Goal. User stories might change as long as they help to reach the sprint goal. The Scrum team delivers VALUE, not user stories or story points. If the change helps to achieve the DEFINED sprint goal, then go for it.
- What is the business value of this change? The delivered benefits of the newly added scope must be higher than the user stories that are already on the sprint backlog. Only then the scope change can be prioritised higher than planned user stories.
- Will the customer use the result of the scope change on release? In agile, we care about cashflow. We invest, and we want to cash in quickly the return of the investment. We invest by creating specifications, developing, designing, testing, etc., and we cash in when the customer uses the functionality. If the customers don’t use the feature, then is a lost investment. Think about it like when you do the shopping for your house. You buy more things because you think like eating something else that’s not in the fridge. A few weeks later, you trash half of the refrigerator because they are expired. That’s was of time for shopping, waste of money spent, waste of whole industry created around it to supply to your food you never consumed and that others cannot use. If you get some friends for dinner and you need to serve them, then it makes sense the change.
- What is the urgency? We have a sprint backlog and a product backlog. The product backlog is a living artefact. Everyone can add ideas; Product Owner makes sure they are priorities and ready for the team to take them into the next Sprint Backlog. In exchange, the sprint backlog is locked in the boundaries of meeting the sprint goal. Is the new change so urgent to put in danger the sprint goal or it can go on the product backlog?
- Exceptions are allowed. But track them and don’t let it become a rule.
- If I add new scope to the sprint backlog, what I remove? You can decide to don’t remove it, but in the end, the team will not do a part of the sprint backlog. I prefer to withdraw from the sprint backlog what is too much to be delivered. Of course, there is the other strategy: push for more, increase velocity. We can always work until burn out, but are we delivering customer value on long term or burn out teams that will take a sabbatical year after several sprints?
Things I don’t consider as change anymore:
- If it’s few minutes thing, less than 1h, and not too many to put in danger the sprint goal. I think the team and we all must be flexible. And I say that because I run experiments on multiple teams, different projects: how long does it take to manage the scope change vs doing the work. Management meetings, estimations, negotiations — this is a waste of time and energy, no value-added. We lose more time (and money) in identifying such things than actually doing it. When I see that they are adding up, then I propose to start tracking them. I ask the teams to add the little things in the project management tool (e.g. Jira, Asana). If it’s too much for the team, the Scrum Master can do it during the standup. This action shouldn’t take more than 30 seconds. The team will use this information at the end of the sprint, during the retrospective. While retrospecting on how the last scrum sprint went, look at the scope deviation and reflect: what was the goal, why we didn’t reach the goal? How can we improve in the feature? I recommend the root cause analyses as a retrospective type for such exercise.
- Clarifications brought during the sprint that doesn’t affect anything is just replacement. Today’s world needs us to be flexible, to adjust. How can we help the customer to get more value?
Conclusion: Independent of your role in the Scrum Team, you are a change agent, embrace the change in a positive way, understand what triggers it and see how you can make the best out of you!
You might be interested in:
https://ancaonuta.medium.com/limit-work-in-progress-wip-9c1085e7a1ed
