Scrum Smells: Going Along To Get Along

  1. Posted on August 5, 2009 6:54:PM by John Clifford to Retrospectives
  2. Methods & Processes, Technique, Agile, Scrum, Management, processes, product owner

A question was posed on one of the Scrum discussion forums recently about changing the sprint backlog during a sprint. The scenario was as follows: the sprint has been running for 2 days when the Product Owner comes to the daily standup and wants to replace a committed sprint backlog item with one of equal size in the product backlog. What should the Scrum Master do?

As this was a real question posed to the forum, I wondered how often the Product Owner comes to the team two days into a sprint to rearrange the sprint backlog? What a stinky Scrum smell this is.

One of the major hindrances to getting something done is the Tyranny of the Urgent. The reason that Scrum keeps the committed sprint backlog inviolate is to provide the team the ability to keep their heads down for the sprint instead of constantly being whipsawed by context switches forced on behalf of the crisis du jour. If the level of uncertainty is very high in an organization, the proper response isn't to relax Scrum rules by allowing changing the sprint backlog during the sprint, it is to shorten sprint duration so the organization (and the Product Owner) know that, at most, they'll have to wait for no more than two iterations to get a specific item.

In my experience, the importance of changing the backlog during a sprint is almost always greatly exaggerated. (The 'importance' is usually due to someone outside the team dropping the ball on a commitment, and trying to cover it up by breaking the Scrum process.) Scrum has a mechanism for ascertaining if it should be done, however, and that is by forcing the Product Owner to make the call on whether or not to abandon the current sprint and replan with the updated backlog. Yes, this will cost up to a team-day. But following the Scrum process is exposing your problem, not hiding it, and there is a problem here. Are you going to address it, or sweep it under the rug by enabling bad behavior?

I know, some people will wonder what the big deal is. Why not just go along to get along? My response is to reiterate that Scrum is as much about improving the organization as it is organizing project work. Why waste a great opportunity for improvement? What I like about this particular scenario is how it shows whether you truly understand that Scrum is really a tool for improving the organization instead of just another way to manage a project or set up the workflow. Sure, you can go along to get along by swapping out backlog items and getting the Product Owner off your back, just as you can put a penny under a blown fuse and get the lights back on, but you haven't solved the problem. In fact, you've made it more likely to blow up.

Others will wonder if this somehow violates the Agile principle of responding to change over valuing a process. I'm all for responding to change. What I'm against is abandoning the Scrum process, and I'm suggesting that there is a very good reason for the few simple rules that Scrum has. One of those rules is that the sprint backlog with the corresponding commitment is locked at the moment commitment is obtained and the sprint starts. Scrum allows for changes to the sprint backlog during an iteration; abandoning the sprint and replanning and restarting a new sprint. As an aside, if you're following Scrum you shouldn't be dropping items from the sprint backlog during the sprint either; that is just a way of hiding what is truly happening. Instead, during the retrospective the team should discuss why committed sprint backlog items couldn't or wouldn't be completed during that sprint, or why the team undercommitted (if new items are continually being dragged into the sprint backlog), and then brainstorms to arrive at a solution to this problem.

Stephen Covey, of Seven Habits fame, says that "courage is integrity at the moment of choice." Scrum, or any other way of doing things, won't work if the people involved lack courage, if the prevailing philosophy is "Can't we all just get along?" instead of "Do the right thing." The Scrum Master needs to demonstrate some integrity in this situation and require the Product Owner to follow the Scrum process. Either abandon the sprint or leave the backlog alone. Then, during the retrospective, a discussion on why the backlog needed to be changed should be held with the goal of trying to figure out what caused this (genuine unforeseeable emergency, bad PO planning, someone dropped the ball on a commitment, etc.) and how to prevent this in the future. Otherwise, expect constant pressure to change the sprint backlog.

Chad said:

August 6, 2009 7:36:AM

Preston Covey?  Do you mean Stephen Covey?

John Clifford said:

August 6, 2009 1:34:PM

Yep, I mean Stephen, not his brother Preston :-) (another interesting read). Thanks for the catch.

John Clifford said:

November 19, 2009 10:29:AM


IMO, the "unspoken" contract of not changing the backlog mid sprint also relates to breaking the collaboration principles... i.e. is a bit like cheating the PO is cheating the team... if it happens once, it starts breaking the trust cycle.

I wrote on this topic a bit more previously in my blog.

yes, yes, self-promotion... but it is relevant!

Victor said:

November 8, 2011 2:47:PM

To me this sounds like a crystal clear case of scrum fundamentalism. "It says in the Scrum manual that I cannot change anything in the sprint, therefore I can't cause then I wouldn't be doing scrum"

Instead, ask yourself if it is beneficial to add the item. Would the customer benefit from it, will this add value to product etc. Don't bother if it's scrum by the book or not.

Confused about modifying the sprint backlog during said:

May 23, 2012 12:08:PM

Pingback from  Confused about modifying the sprint backlog during a sprint | DIGG LINK

Post a Comment:


John Clifford

John Clifford is a Senior Fellow and Agile Practices Lead at Construx Software. John got his first software development job at a startup, while still in college, in the early 1980s. He started and ran a successful software company when he was 23. His career includes almost six years at Microsoft, where he was one of the original developers on the Microsoft Project for Windows and Mac team.

With more than three decades of IT experience, John has developed software across the spectrum of computing environments, ranging from desktop and mobile device applications to low-level frameworks, device drivers, and asynchronous communications protocols. Prior to joining Construx, John’s career included stints as a software development engineer, product feature team manager, group QA manager, group project manager, and development director.

At Construx, John focuses on software development, project management, product management, and team and organizational management practices, with an emphasis on Lean and Agile methodologies. As a manager, and as an external consultant, John has led numerous successful organizational transformations to Scrum and Lean/Kanban. He holds Certified Scrum Master, Certified Scrum Product Owner, and Certified Scrum Practitioner certifications from the Scrum Alliance. John was invited to become one of the charter Kanban Coaching Professionals from the Lean Kanban University, the professional association and standards group for Kanban Method training and coaching. As an adjunct instructor, John also teaches a course on applying Lean and Agile principles and practices for the University of Washington’s Professional and Continuing Education program.

Contact John