Is it possible to remove Stories during a Sprint in Scrum?

Question

Scenario

In our organization, we use velocity to forecast the amount of possible work in a Sprint. Sometimes, based on the Team's average velocity, we add extra features not related to the Sprint Goal, just to add more value if the Sprint Goal's tasks are not enough.

Sometimes, these extra features couldn't be completed, and we have to end the Sprint as a failed Sprint because we couldn't completed the stakeholders' expectation.

Question

Is it possible to remove Stories, even in a running Sprint?

Answer 1

TL;DR

By defining success as "doing all the things," rather than "doing the right things," your process inherently sets the team up for failure. Instead, leverage the framework (especially the Sprint Goal and the Definition of Done) to correctly the measure the value the team is delivering.

Setting the Team Up for Failure

Sometimes, this extra features couldn't be completed, and we have to end the sprint as failed sprint because we couldn't completed the stakeholders spectation.

This is wrong. Setting aside the question of whether you should accept work into a Sprint that isn't related to the Sprint Goal, not completing "extra work" doesn't mean you have a failed Sprint.

CodeGnome's Scrum Tautology says:

Always remember that the goal of a Sprint isn't to complete lots of backlog items. The goal of a Sprint is to deliver the Sprint Goal.

Ignoring the tautology is an aspect of the 100% utilization fallacy. Focusing on how much work the team does, rather than how predictably they deliver working product increments, is a very whiffy framework implementation smell.

A successful Sprint is one that meets the defined Sprint Goal and delivers a potentially-shippable increment per the Definition of Done. Any other definition is self-sabotage.

Scrum Theory

The Scrum Guide's section on Scrum Theory doesn't even acknowledge the concept of a "failed Sprint." Instead, it treats process or delivery issues as inspect-and-adapt opportunities. It says:

If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.

In principle, this means the only "failure" is a failure to apply Scrum principles such as setting a coherent Sprint Goal, renegotiating scope with the Product Owner as needed, or cancelling a Sprint when required.

See Also

• Sprint Goal and Failure of a Sprint
• What are the right conclusions to draw from the success or failure of a Sprint?
• What to do when mid-sprint, you realize some stories won't be done?
• Why must we define a Sprint Goal for each Sprint?
• What can we do with a "mispointed" story in Scrum?
• When Scope Changes Mid-Sprint

Answer 2

To answer your question at a basic level, if you want to change sprint scope while the sprint is running, the backlog items you change need to be an equivalent size. For instance, if you need to add a 5 point story to the sprint, you could remove a 5 point story from the sprint. Or, you could remove one 2 point story and one 3 point story. The sprint commitment therefore stays the same - you're not doing extra work.

You didn't say if you were doing this or not, but don't remove anything from the sprint if it's marked as in progress, as this will disrupt the team's work.

Achieving the sprint goal should be your aim. If there are additional things that you'd like the team to do if they get through the sprint backlog faster than expected, consider having those as stretch goals. With this method, you don't need to add them directly to the sprint and you don't need to take anything out. If the team completes the sprint backlog early, they could take the highest priority item from the list of stretch goals and bring this into the sprint. It needs to be something that can be completed within the sprint - so be careful with adding large items towards the end of the sprint. If the stretch goals are not completed, the sprint has not failed. Stretch goals are additional work - they are not your sprint goals.

Failing a sprint can be very demoralising for the team, and seems like it could be prevented if it is happening because of items added to the sprint that do not relate to the sprint goal.

If stakeholders ask for more work while the sprint is running, all you need to do is say that the work can be considered for a future sprint.

It would be helpful to know what your role is, as you didn't say. That might be another question though.