Reacting to Change & Abandoning Sprints

I’ve been asked quite a few times recently what I think about the idea of abandoning a sprint (in Scrum) and how to deal with change in an agile project that happens in-iteration, so I thought I should lay out my opinions on it here.

In Scrum, the user stories in the sprint backlog are fixed during sprint so that “the team is left alone during the sprint to accomplish the goals to which it initially committed”. If something comes up before sprint end you have two options:

1. Wait until start of next sprint
2. Abandon the sprint and start again from now

On projects with longer sprints an early abandon may be favoured over continuing, but I still think that abandoning a sprint is a pretty drastic thing. I would favour instead estimating the new item, removing an unstarted item from the current backlog with sum greater effort than the interrupting item and start on it instead, if it really is high priority.

Abandoning sprint seems like a the nuclear option to discard current progress even if has been valuable, and this scariness is used to ‘teach’ the customer about not interrupting a sprint because then whoever made pushing that button necessary is going to have to explain it to the whole project.

Abandoning the current iteration may also result in lessons learned being wasted, as retrospectives may not be performed as team jumps straight into planning and estimation the new high priority stories.

But is interrupting a sprint so bad? If entire purpose of current work somehow becomes obsolete, it certainly makes no sense to continue it. Finding out that the stuff you’re doing won’t be valuable means you should stop right now rather than soldiering on to the end - but if something comes up that must be tackled for whatever genuinely important reason, and the current work still is valuable, why not just refocus on the new priorities?

If the customer is changing their minds all the time during the sprint anyway, they should simply be educated on the overheads they are causing, and the product owner should be working more closely with them to plan and analyse upcoming and important requirements better.

If you have to abandon sprints often then it is an indication that the customer is not engaging with the product owner in appropriate planning and analysis, but this may be less of an issue if the sprint length was one week instead of four weeks.

I think that the reason abandoning sprints is the only option other than ignoring the request is because in particular, on a project with longer sprints like four weeks, you’re really only reacting to change every four weeks. Shorter iteration lengths result in the ability to more frequently change course if needed even if you are religious about preventing any mid-iteration change.

I would prefer that the requirement is accepted into the sprint and that a greater-sized requirement is pushed out in return (to account for overhead of new estimation and context switch), and the reasons for why this unusual circumstance occurred were discussed with the customer and team during retrospective and end of iteration demo. Find out what the team thought of the change and how disruptive it was and communicate this clearly back to whoever insisted upon it, and ensure that this is a rare event.

Overall I favour shorter sprints to address this, especially if you have trouble with often being interrupted. The more frequently that the team can react to change and the more frequently you can inspect and adapt the better.

How do you handle sudden changes in requirements on your projects? Do you interrupt, ignore or abandon? Or are you using a more continuous process like Kanban, which could perhaps be better at dealing with this?