In my last One-on-One with my Fearless Leader, I mentioned the challenges that my team is currently facing with getting out in front of unknown impacts. Lately, we’ve been hit with unexpected work: from minor feature requests and enhancements to new applications to support – it would be great it we could get a bird’s eye view of these anticipated items so that we can fit them into our Roadmap and Sprint Plan. Our company divides work across several Portfolios – there is a many-to-one relationship between Teams to Portfolios. Our team manages to get a decent heads up when work within our Portfolio is going to hit us – what we are struggling with is the work that initiates outside of our Portfolio. So, I brought this concern to my Manager and, as usual, he flipped the script on me.

He relayed that, while it’s always great to try to get better visibility into the unknown, it’s even more important to welcome it. He went on to note that our company is particularly change averse and that THAT is the true opportunity for improvement.

Let’s dig into this a little. I have been taught (and therefore practicing) that, as a Scrum Master, I should fiercely protect Sprint Boundaries – Meaning that once my team undergoes Sprint Planning and sets the Sprint Goal, we should closely analyze any proposed changes to the Sprint with a questioning eye – like this:

1) Does this proposed change fall in line with the Sprint Goal?

2) Does the team have capacity to absorb the change? If not, Mr. Business Stakeholder, if this change is sooooo important, what do you propose that we REMOVE from the Sprint to accommodate it?

In hindsight, this behavior is not quite one of a team who is welcome to change. So, have I been missing a critical component of Agile and Scrum, in particular? Let me check the rule books.

The second Principle of the Agile Manifesto states, “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” Well, snap.

What about the Scrum Guide? It states, “During the Sprint: No changes are made that would endanger the Sprint Goal;”

It goes on to indicate that the best course of action, if a substantial change is proposed that would jeopardize the Sprint Goal, is to cancel the Sprint altogether:

  1. Any completed and “Done” Product Backlog items are reviewed.
  2. Deploy any potentially releasable work.
  3. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog, realizing that the work done on them depreciates quickly and must be frequently re-estimated.

My initial reaction is that this is a much more rigid interpretation of the spirit of the Agile Manifesto – and frankly, it doesn’t seem to welcome change much. The undertone is more negative and leads one to believe that any change to the Sprint is an undesired behavior. But digging deeper, there is subtlety in the words of the Scrum Guide. It places more weight on the Sprint Goal itself – if the Goal is crafted with thought, it is quite possible that the unplanned work will fit nicely inside. And if not, the next iteration should be right around the corner. This all means that it should be a rare occasion where the team should have to resort to canceling the Sprint.

All this being said, there is no denying that the Scrum Guide has a bent on NOT changing the Sprint.

For what it’s worth, our team hasn’t been following the Scrum Guide in this regard. When significant change hits us mid-Sprint, we’ve:

  1. Panicked
  2. Estimated the work at a story-point level
  3. Pulled the new cards into the Sprint
  4. Removed the same number of story points from the Sprint in descending priority order
  5. Moaned and groaned throughout the remainder of the Sprint about how our Sprint was thrown off-course.

I do believe that there would have been value in following the steps to cancel the Sprint, if the proposed changes wouldn’t have jived with the Sprint Goal (and in our recent examples, it wouldn’t have). Canceling the Sprint would have:

  1. Given the team a chance to reset and absorb the new work mentally.
  2. Showed the business the impact of the unplanned work on our team so that we could, potentially, make different choices next time. Or not.
  3. Allowed us to deploy the potentially-releasable work that we have completed, giving the team a sense of accomplishment in what was done during the Sprint.

So, where do we go from here? Continue to fiercely adhere to the Scrum Guide although it seemingly conflicts with the spirit of the Agile Manifesto? Do away with the Scrum Guide in this regard or altogether? (After all, Kanban has been softly knocking at our door for some time now) Let’s not be so drastic. Perhaps a simple mind-shift is all that is needed. I propose a three-pronged approach:

  1. Talk to the team about the Spirit of the Agile Manifesto where change is concerned. Ask them what we can do to become more open to change. Talk openly about the Scrum Guide and it’s bent towards “protecting the Sprint”.
  2. Reiterate the importance of the Sprint Goal and choosing it PRIOR TO the selection of the Sprint Backlog.
  3. When unplanned work hits the team, Cancel the Sprint with a positive attitude!
  4. Continue to work with Leadership and the Business to get better visibility into cross-Portfolio Roadmaps to plan for work that could potentially impact our team.


How does your company/team handle change? How do you view this perceived conflict between the Agile Manifesto and Scrum Guide? Does Kanban lend itself to more flexibility in this regard?