How Do We Handle Scope Creep in Scrum?

  • Post author:
  • Reading time:3 mins read
You are currently viewing How Do We Handle Scope Creep in Scrum?

Scope creep is common in projects and refers to changes in requirements that diverge from the original agreed-upon work and risk derailing the schedule, delaying the delivery date, or increasing the project’s costs. In traditional project management, the scope is tightly monitored and managed to ensure minimum new changes are introduced to keep things on schedule and within budget.

What about scope creep in Scrum and how do we handle it? In short, there is no scope creep in Scrum. Not because requirements do not change, but because we welcome changes as per principle 2 from the Manifesto for Agile Software Development:

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Here are 5 things to consider regarding Scope changes and Scrum:

  1. One of the main reasons to use Scrum is for situations with high uncertainties, unknowns, or risks. Situations when we don’t know what is needed, what might be valuable, or how we are going to get it done. In other words, situations when the scope can’t and shouldn’t be fixed.
  2. Scrum is based on empiricism, which means we gain knowledge through our experience. The idea behind a Sprint is to try something, see how it goes, learn from it, get feedback, and then decide what to do next. There is continuous discovery and delivery in Scrum.
  3. The Sprint Review is all about welcoming changes based on what has been built so far, ensuring we are always working on the most valuable things.
  4. For these reasons, by definition, the Product Backlog is never complete. It is dynamic, always changing, frequently modified, and updated. New items are added or removed from the Product Backlog all the time based on the latest feedback and learnings. In other words, the scope is always changing.
  5. To allow the team to focus on the Sprint Goal, changes are not brought in directly into the Sprint Backlog, but into the Product Backlog for the Product Owner to assess and determine importance and plan accordingly for future Sprint.