Can the Sprint Goal Be Altered? Yes!

The title of this post is somewhat of a contradiction, but I am OK with contradicting myself from time-to-time.  On the Certified ScrumMaster’s LinkedIn group there was an interesting conversation about what should a Team do when they have finished all their work before the end of the Sprint.  Other people had commented earlier on the thread about some effective strategies and my unique contribution was that if the Team is done, they should help other Team members or other Teams who are not done.

Then the thread took a more interesting turn as one commenter quoted Jeff Sutherland in his recent book, Scrum: The Art of Doing Twice the Work in Half the Time, and cited a specific passage that says the scope of a Sprint is locked after Sprint Planning.  While in most situations, I would tend to agree with that Scrum by-the-book should be followed and Scrum by-the-book says once the Team’s commitment to the Sprint Goal is made at Sprint Planning, it cannot be altered.  If we allow too much flexibility, that will create too much thrashing and lack of focus on the Team.  Additionally, letting the business change their priorities after Sprint Planning does not encourage the business to make commitments regarding their priorities nor does it reinforce the Product Owner’s accountability to be ready and prepared in time for Sprint Planning.

However, then we have Scrum in-practice and things get a little messier.  When working with Teams and organizations, I encounter a number of scenarios that occur often enough on which suggests for the need to flex the rules (but not break them).  If Scrum does not serve the business, then the business will not support the continued application of Scrum.  However, we also need to be disciplined in our application in Scrum because then Scrum becomes whatever we say it is and that does not work either.

When flexing the Scrum rules, our solution must be based on the Scrum values and principles and continue to honor various rights of each role.  In these types situations when scope and priorities are changing, there are three principles that are foremost in my mind.  First, the Product Owner has the right to receive the most value out of every week.  Second, the Stakeholders have the right to change their mind, substitute functionality and alter priorities without paying an exorbitant cost.  Third, we have to maintain the focus of Team and prevent interruptions and distractions as much as possible.  These three principles have to be balanced against the rule in Scrum that says, “Once the Team commits to the Sprint Goal it cannot be altered.”

Now for my scenarios.

1.  Team finishes their commitment early – in this case the Product Owner has the right to take a small item from the Product Backlog that can be 100% finished, i.e. meets the Definition of Done, before the end of the Sprint.  No picking a feature just to get a head start on the next Sprint otherwise the product would not be potentially shippable at the end of the Sprint.
2. Product Owner recognizes that an unstarted Product Backlog item (PBI) does not need to be delivered – in this case the Product Owner can choose to swap the PBI for another more valuable PBI of equal, or smaller, size.  We have to recognize that priorities change in business and if feature is truly not needed, the business should not have to pay for something they do not want nor need.  I call this swapping of an unstarted feature for a different feature in the Product Backlog “the exchange”.  It is not a replacement for poor preparation on the Product Owner’s part.  Also, if the feature has been started and the business decides they do not want it, too late – no exchange.
3. Team learns that the technology will not support the feature – a lot of Scrum planning in Scrum is speculative and based on assumptions of what is possible with the technology.  From time-to-time, the technology just does not work.  In this case the Product Owner can simply remove the PBI from the scope of the Team’s commitment and can select a new PBI of equal or smaller size, if agreed upon by the Team.  Another option for the Team and the Product Owner is to replace the feature with a spike.  Spikes are not replacement for engineering diligence on part of the Team.
4. The Sprint Goal no longer provides the business any value – in this case the Product Owner can opt for a Sprint Termination and re-plan with a new Sprint Goal using the time remaining in the Sprint.  In my ten years of doing Scrum, I have only used a Sprint Termination once and that was mostly due to my own ego.  In almost all cases, something of value can be salvaged without terminating the Sprint.  However, I consider Sprint Termination the sledgehammer one uses when everything is all FUBAR.