Is it appropriate to blow up a sprint?
We were several sprints in with a new team and suddenly the team was faced something new. Something out of their control caused havoc with the priorities in the Backlog. The work that the Scrum team had committed to for the sprint was no longer needed. In the Sprint Review the scrum teams voiced that we did not meet our original goals. The teams and the product owners were hard-voiced about having to “blow up the sprint” and having to “re-plan and re-baseline”. There was a discomfort level and some confusion within the team as to whether we might have done the right thing. The strongest statement was, “The institution of scrum was disrespected.”
The Cliff Notes Answer
Leadership, stakeholders, coaches, and scrum authors say we all made the right decision and behaved correctly. Changing our sprint backlog in the middle of the sprint made sense because it honored new business objects and the desires of our Product Owners. The scrum play book says it is perfectly fine for teams to break the sprint this way as long as this is the rare exception rather than the norm.
The Detailed Answer
As I am talking with the team I will start this out with saying “GOOD JOB”
and end my conversation in the same way. I start asking QUESTIONS.
When is it appropriate to Blow up a sprint and re-plan/recommit?
Are we allowed to do it? Sure.
Always I want to ask questions. The first one is obviously Why?
Is this a BIG Deal? I think it is. Firsts often are.
Were our assumptions on the sprint goals wrong?
What risk did we not think about critically?
What wasn’t communicated?
Does this still make sense?
Were the release themes not vetted from above and below?
Was everyone on the same page for acceptance criteria for the stories?
What changed our assumptions?
How can we prevent this from happening again?
The Team did A LOT of work!
We adjusted to the highest priority!
Will the business expect this as common practice?
How disruptive was this?
What was the impact? Did we lose 3 days of our sprint?
What did we learn?
How do we improve?
I write this after the fact because we are empowered to make these decisions.
Don’t regret the decision – learn and adapt. You have also worked through a fairly large and complicated problem.
You have changed, and will continue to change some of the assumptions we have together, as an organization.
————–Here are some external references from the proverbial Agile Library:
Succeeding with Agile (Mike Cohn) pg 282 “I usually advise Scrum teams to start taking a firm stance against mid sprint changes. This is not because I am Opposed to redirecting a team or because I want to slavishly obey a Scrum Rule. It is because I want to help those outside the team learn that there is a cost to redirecting the team. Of course, sometimes redirecting a team mid-sprint is necessary. But, all too often teams are redirected because it’s easy to do and because someone didn’t think ahead. I relax this hard-line stance against change after I see the organization no longer thinks of every new request as an emergency worthy of a mid-sprint change. Being responsive is what has made us successful, and users expect that of us.“
Exploring Scrum: The Fundamentals (Doug Shimp and Dan Rawsthorne) 1rst ed. pg 268 “Cancelling a Sprint. The product owner may cancel a Sprint at any time, usually because the Sprint Goal isn’t going to be met or because the Sprint Goal is no longer what is needed. In either case, the Sprint’s work is evaluated to see what can be kept, and whether or not a replanning is called for. This is not considered abnormal, but it is simply an agile reaction to something that has happened. It should not be considered a ‘bad thing’ – it is merely a ‘thing’.”
Scrum Product Ownership (Bob Galen) pg 110 “Adjusting the Sprint. … In fact the leader here should be the Scrum Master. He or she is your partner and should guide you in making any necessary adjustments, etc. However you do play a significant part in the Sprint recovery process, too!
CONTENT DISCONNECT. The team is struggling to deliver the Sprint contents. Within a few days of the Sprint, you and the Scrum Master realize that an adjustment is necessary. I’ve seen several approaches to this. Classically, Scrum allows for cancelling and re-planning your Sprint. That works well if you’re a stand-alone team. However, if your team is synchronized with others, then this approach can be awkward in that you’ll need to plan a reduced length Sprint in order to maintain your Synchronization. … I’ve seen teams significantly recover their progress and often meet the original Sprint Goal. …
PRIORITY DISCONNECT. … In these cases he (product owner) was more likely to cancel the sprint and then re-plan a new one based on a major shift on the backlog. However when re-planning we tried to stay open minded about integrating the new work and maintaining some of the original Sprint focus. Another aspect of this is insufficient look-ahead. I was never convinced that we couldn’t anticipate these changes in some way. Remember, we were on a 2 week sprint model which is fairly nimble.”
Changing direction doesn’t come for free. We are trying to be agile and make adapting lightweight – but a team’s capacity to do so is not infinite. The time and impact required to pack up what we were focused on, and then re-plan should not be ignored. When we commit to a backlog at the beginning of a sprint, the team is serious about delivering the work and trusts that they have everyone’s support and are allowed to maintain this focus in order to deliver. Unanticipated work in the middle of a sprint distracts. If a team starts to believe their commitments will be ignored, the erosion of urgency, commitment and trust start to occur. Loss of trust erodes team morale and we’ll eventually find ourselves back to where we started. In quiet silos with being defensive about collaborating. Our ability to fail early is not a joke. It is instead a measurement for how quickly can we get to right.
A message like this should be visible enough to encourage the team we did the right thing. Some VPs, a few Directors, coaches and half a dozen managers as well as the teams themselves needed to know and think in a manner where there was no ‘us’ vs ‘them’. There is only “WE”, together. As in WE will make this better and work together so that it shouldn’t happen again. As well as, we will be thought-full about the “But if it does…”. This is what transforms the organization, delivers great software, and as a side-effect, makes some high performing teams.
If you’ve made it this far, thank you for reading through the details.