I had a very interesting discussion with an experienced Scrum person the other day which caused me to investigate why I held a different view from them. This person challenged me on my dislike of the Scrum practice of “Terminating the Sprint” if the product owner comes to the team with urgent work. We held different views: I expressed my view that terminating the sprint was never necessary, and he expressed that it’s the underlying principle of development teams in Scrum. There is a good argument for both.
Note that when I use the term “Scrum master”, this relates to whichever term is used in your teams (e.g. Iteration Manager, DevOps Manager, Team Coach) and not directly to Scrum.
The Scrum Alliance talks about Abnormal Termination of a Sprint and gives these guidelines. Reasons for an Abnormal Sprint Termination may include, but are not limited to:
The company changes direction
Market forces render the work obsolete
A major technology change occurs
A better technical solution is found that makes the current Sprint’s activity throwaway work
Fundamental and urgent external changes that invalidate the Sprint Goal or the bulk of the functionality
Urgent bug fix or feature development request that cannot wait until the normal completion of the Sprint
Sounds reasonable, doesn’t it? After all, if the team is working on something that no longer has any relevance, why continue?
This person also put forward another very valid argument: He said that this allows teams to deliver to their commitments without interruption and surely anything, no matter how urgent, can’t wait until the end of the Sprint, and if it just can’t, then we abandon Sprint as the last resort.
I thought differently but had to look into the reasons why as I enjoy and promote Scrum as a means towards Agile, and this person’s view is valid.
After thought, I realised that this comes down to the differences between Scrum and Agile. Remember Scrum is not Agile, it’s a framework. That’s a fundamental difference that needs explanation.
Agile is a mind-set that is governed by the four values described in the Manifesto and following the 12 Principles of that Manifesto.
Scrum is a framework consisting of a set of procedures, rules, and ideals. Scrum was defined many years before the Agile Manifesto was created.
I like Scrum as there are few rules, which allows us to follow the Manifesto and 12 Principles – however, the Scrum Rule around Abandoning a Sprint seems to go against the second Agile Principle:
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage
Even more than that, the third value of the main manifesto itself states that we value…
Responding to Change over Following a Plan
So what then would I suggest in its place?
Let’s say that business finds that in order to implement something absolutely necessary, and has so much value, that it must be implemented as soon as possible. Following Scrum, the Scrum Master and Product Owner calls for the Sprint to be terminated and a new Sprint Planning session is created.
However, I propose that we follow the Agile Principles here. If Business can convince the Product Owner that this new need is of greater value than the work currently underway – remember, he/she is the owner of the Priority – then the Product Owner will approach the Scrum Master.
While the Scrum Master is in charge of the Sprint Backlog, and while they will always lay great value in the direction of the Product Owner when it comes to priority, they must be convinced that this is worthy of changing their Sprint Backlog. Once the Product Owner and the Scrum Master agree that this piece of work is of higher value than the current work, then they will both go to the team.
At this point, the team can size the new work. If this new work can and should be done within the current Sprint, then the team has a decision to make:
If the team is ahead, and this new work is small enough that it can be included in the Sprint without change, then they will accept the new work
Otherwise, the team will ask the Product Owner which outstanding piece(s) of work of equal estimate, should be dropped off this Sprint in order to deliver the new work.
In this way, not only can the team follow the Agile Manifesto for welcoming change, but the team themselves get a kick out of showing how well they can respond to this change and deliver great value to the organisation as per the Agile Principle of welcoming change.
It’s a win-win situation.
Terminating the Sprint has several downers that must be considered:
A Product Owner will only present to the team what is currently uncompleted in the Sprint plus the new high-value story. Your new Sprint will not gain anything in this case
To start a brand new 2-week Sprint from a new point, the general cadence is broken. Previously the team, other teams, plus the business has set up their habits around the Sprints and the Showcases and now many planned meetings may have to be reorganised around this new change
While some teams simply start a smaller Sprint consisting of the number of days remaining in the Sprint, this seems contrary to any reasonably perceived gain for abandoning a Sprint.
However, there are also several Pro’s relating to terminating a Sprint
Stops a Product Owner being lazy or not properly engaged and constantly “remembering” this new urgent requirement that has been in the backlog all the time. This may be due to a Product Owner having several other roles or working for several teams and simply don’t have enough hours in the day to correctly prioritise.
A Product Owner and team may come under unreasonable pressure to say YES to every new idea if the change is that easy.
There is a certain disruption to a team and if done often, can lead to lower productivity. Terminating the Sprint, in this case, is visible and questions are then asked.