Day six of a ten-day sprint, a message arrives: "Could you squeeze this in? It should be tiny." It usually is tiny. That is exactly the problem, because nobody refuses tiny, and by day nine there are four tiny things in the sprint and two of the stories you planned are still in progress.
Here is the short answer. You can add work to a sprint that has already started, and the Scrum Guide is fine with it. What you cannot do is add work for free. If something goes in, something of similar size comes out, and the test for what comes out is the sprint goal.
Can you add stories to a sprint after it has started?
Yes, and it is worth being precise about why, because teams tend to treat the sprint as either sacred or meaningless.
The Scrum Guide says the Sprint Backlog "is updated throughout the Sprint as more is learned", and that "scope may be clarified and renegotiated with the Product Owner as more is learned." So the plan is supposed to move. The same section sets one hard limit: "No changes are made that would endanger the Sprint Goal."
That limit is the whole rule. Adding a story is allowed. Adding a story that makes the goal unreachable is not, and adding one on top of an already full sprint almost always does, you just do not find out until the last day.
Not everything added mid-sprint is creep
Before reaching for the rule, sort what arrived. Three different things get called scope creep, and only one of them deserves the name.
A bug in something you finished this sprint is not new scope. The story was not done, it only looked done. Fix it inside the sprint and have a quiet look at your definition of done afterwards.
A story that turned out bigger than it looked is not new scope either, though it hurts the same. The team learned something. If what you learned changes the size of the whole story, re-estimate it. If it is only taking longer than hoped, leave the number alone, for the reasons in our post on sprint spillover.
A new request from outside the team is the real thing. It was not in the plan, nobody committed to it, and it competes with everything that was. This is the one the swap rule is for.
The swap rule: one in, one out
When a genuine new request lands, the question is never "can we fit this in?" The answer to that is always a hopeful yes. The question is "what comes out to make room?"
Say the team committed to 34 points and the request is a 5. The Product Owner looks at the sprint and picks roughly 5 points that matter least to the sprint goal, and those go back to the backlog. Not deleted, not failed, just not this sprint. The total stays at 34 and the goal stays reachable.
Sometimes nothing in the sprint matters less than the new thing. Then the new thing waits for sprint planning, which is at most a couple of weeks away. That is worth saying out loud to whoever asked, because "next sprint" sounds far less final once people know when next sprint starts.
And once in a while the new request makes the sprint goal pointless. A customer churned, the feature is no longer wanted, the priority really has flipped. The Scrum Guide has an answer for that too: "Only the Product Owner has the authority to cancel the Sprint." It is rare, it is allowed, and it is more honest than dragging a dead sprint to its end date.
Who gets to say no?
Not the developer who got the message. The request should never be settled in a direct message between a stakeholder and whoever on the team seemed friendliest.
The Guide calls the Sprint Backlog "a plan by and for the Developers", so the team owns what is in it. The Product Owner owns the priorities, so they decide what gets swapped out. Put those together and the path for a request is simple: it goes to the Product Owner, who decides whether it beats something in the sprint, and the Developers confirm the swap is real in size.
The line a developer needs is short. "Happy to look at it, can you run it past our product owner so we can see what it replaces?" That is not a refusal. It is sending the request to the one person who can make room for it.
Count it, or it will keep happening
Scope creep survives because it is invisible. Each addition is small, nobody writes it down, and at the retrospective the team remembers the sprint as "busy" rather than as "34 points planned, 42 points in the sprint by day nine."
So count it. At planning, note the committed total. At the end, compare it with what was actually in the sprint. The gap is your creep for that sprint. After five or six sprints you have a pattern, and a pattern is something you can plan around.
This is also where your chart choice matters. A burndown hides added work inside the same line as progress, so creep looks like the team slowing down. A burn-up with its own scope line shows it as the target moving. We went through that difference in burn-up vs burndown.
When creep is the plan, plan for it
Some teams will always get interrupted. A team that also looks after production, or one that serves a sales team with live deals, will see new work every sprint, and pretending otherwise just produces a missed commitment every sprint.
If your count says roughly five points arrive unplanned each sprint, commit to five points less than your velocity and keep that slack free. It feels like planning to do less. It is planning to do what you actually do, and meeting a commitment for once is worth more to the room than a bigger number you miss.
And if the unplanned work regularly outweighs the planned work, be honest about it: you may not be running sprints at all, just a queue with meetings around it. A continuous flow might suit you better, and there is a fair comparison of the two in scrum vs kanban.
What this looks like in Scrumpy
Straight answer, since this post leans on one chart feature we only partly have.
When you plan a sprint, the sprints page shows the committed points against the team's velocity, the average of its last five finished sprints, so you can see whether the plan is already full before anyone asks you to squeeze something in. The sprint has a goal field, which gives the swap rule something to test against. When the sprint ends, its point total is locked, so later backlog changes do not rewrite what the sprint held.
The sprint burn-up on the dashboard shows completion against a working-days target, green when you are ahead and amber when you are behind. What it does not do yet is draw scope as a separate line. Add a story on day six and you see the percentage dip, not the target step up. So for now, note the committed total at planning and compare it at the end, the way this post describes. It takes one line in the sprint goal.
Next time the "tiny" message arrives, do not answer the question it asks. Ask what it replaces.
Frequently asked questions
Can you add stories to a sprint after it has started?
Yes. The Scrum Guide expects the Sprint Backlog to change as the team learns more, and says scope may be clarified and renegotiated with the Product Owner during the sprint. What it rules out is any change that would endanger the Sprint Goal. In practice that means new work can come in, but something of similar size usually has to come out.
What is scope creep in a sprint?
Scope creep in a sprint is work added after sprint planning without anything being removed to make room for it. Each addition tends to look small, which is why it creeps rather than arrives. Over a two-week sprint a handful of small additions can add a fifth to the plan, and the team then misses a commitment it would otherwise have met.
Who decides whether new work can enter a running sprint?
The Developers and the Product Owner decide together. The Sprint Backlog is a plan by and for the Developers, so nobody outside the team should push work into it directly, and the Product Owner owns the priorities that decide what gets swapped out. A stakeholder with an urgent request brings it to the Product Owner, not to a developer.
How do you measure scope creep in a sprint?
Write down the sprint's committed story points at planning, then compare them with the total when the sprint ends. The difference, minus anything that was removed, is the scope that crept in. Tracked over five or six sprints it becomes a number the team can plan around, for example by committing to less than its full velocity.
