How to deal with Change of Requirements or Scope Creep in Agile?

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?

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

Things I don’t consider as change anymore:

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

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:

👩🏻‍🔧 — Scrum bot for Discord 🎯Agile Coach📍Lille, France, 🚀AI Entrepreneur, 🛠Trainer, 🎢Traveler

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store