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?

up vote 5 down vote accepted

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

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.

  • 3
    The point-for-point rule is a good heuristic, but I've seen it taken as permission for people to arbitrarily swap stories, which is not right. The Scrum Guide specifies that the PO and Dev Team may renegotiate the scope during the sprint if needed, so that conversation still needs to happen and the size of the items may be different if they agree to it. Also, +1 for pointing out that achieving the sprint goal is the aim. – Daniel Aug 31 at 19:09
  • It might be worth pointing out explicitly that a sprint is only failed if you don't meet the goal, it's not failed just because there's still work on the board. – Erik Aug 31 at 20:44
  • I think is a good practice swapping stories with the backlog, usually when have blocking stories and cannot continue with, but in this scenario, the new stories still have the problem of time and still being away from the sprint goal. – Josbel Luna Aug 31 at 21:19

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.