

Class Registration
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.