Scrum by Example – Scrum Anti-Patterns & Unplanned Work Disrupting the Sprint

The Team is in the middle of a Sprint, but the Product Owner has discovered unplanned work and interrupts their flow mid-Sprint to deal with it because it’s now “high-priority.” How should a ScrumMaster deal with this or similar Scrum Anti-Patterns?

An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. ~ Definition from Wikipedia

Dramatis Personae

Steve – a new ScrumMaster and the hero of our story
Paula – the Product Owner of Steve’s team

The Story So Far…

ScrumMaster Steve, Product Owner Paula, and the rest of the Scrum team have started another Sprint for building the World’s Smallest Online Bookstore. Having learned the consequences of over-committing, this time they have committed to fewer User Stories and are about halfway through the Sprint. They have committed to eight User Stories with sizes ranging from 2 – 8 points:

• As a Canadian book buyer, I want the World’s Smallest Online Bookstore to ship my book to Canada so I can get my book home – Story Points: 8
• …to calculate the import duty on my books – Story Points: 3
• …to calculate the local sales tax – Story Points: 2

Every couple of days, they get a User Story accepted. Things are going just as planned.

A Scrum Anti-Pattern of the Product Owner and ScrumMaster

Five days into the Sprint, Paula interrupts the team and asks that they add in a new User Story and it needs to be completed during that Sprint. The Story is one that the team had previously sized as 5 Story Points: “As an American book buyer, I would like to use premium shipping so I can get my books sooner.”^[1] However, this “Premium U.S. Shipping” User Story is one that both the Team and Paula had previously agreed was not an urgent priority. Paula says it’s really important now because she’s under a lot of pressure from the product investors to get books to American customers sooner. Steve explains to her that the team has made a commitment for the Sprint and it can’t be changed without cancelling the Sprint. Paula continues to press, saying it is a top priority.

A Failure to Respect Scrum Roles

This is an example of a Scrum Anti-Pattern that significantly harms the ability of the team to manage the scope of their Sprints. This scenario isn’t uncommon, especially for teams and organizations new to Scrum – almost every Scrum team will find themselves in this difficult situation, or one similar, at least once.

In this case, the Product Owner has fallen into a micro-managing mindset, imposing their will on the team by assigning work without consulting them or respecting their capacity to self-organize.

The ScrumMaster is also partly responsible for situations like this: it is their responsibility to prevent other stakeholders, including the Product Owner, from disrupting the team’s workflow. Remember, a Scrum Team self-organizes without the intervention of managers or the Product Owner and the ScrumMaster role defends their ability to do so.

What to Do When Sprint Flow is Disrupted

So what are the Team’s options?

• Refuse the Product Owner’s request – For Scrum to be practiced effectively, the team’s time boxes and Sprint Backlog, as well as their capacity to self-organize their own work, must be respected.
• Switch User Stories – If the team determines that this is a manageable or one-off request, they could choose to trade out a larger User Story for the one that the Product Owner wants to insert, allowing flexibility while ensuring they have enough capacity to complete everything in the Spring Backlog. This also acknowledges that even though the team hasn’t “started” the User Story that would be removed, effort has already gone into its analysis and design. In addition, it forces Paula to recognize that her request has consequences. It is important to send a strong signal that this is not a good idea and will harm the team if used repeatedly.
• Cancel the Sprint – In light of this change in needs, the team and Product Owner can agree to end the Sprint prematurely. As a general rule, this should be the option of last resort because they have come to recognize a radical change in direction is required, or a change in requirements would result in the planned work of the Sprint to be wasted.  (In this scenario, Paula’s request does not justify this).

Handling a Scrum Anti-Pattern the WRONG Way

Steve knows all of the above choices: He could hold a team meeting, invite Paula to explain her request and discuss the “Premium U.S. Shipping” User Story she wants to add. Steve could explain the trade-offs, offering the team the different options, then let them decide the best course of action, perhaps using decision-making tools like Fist of Five Voting or something similar to select the best choice.

However, Steve doesn’t do any of those things —Cracking under the pressure from the Product Owner, the team adds the additional User Story for premium U.S. shipping into the Sprint without trading any other Stories out. Because they had not adequately planned out the new User Story and had lost momentum from the disruption in the previous Sprint, they not only fail to deliver the premium U.S. shipping, they also fail to deliver on another User Story they had planned for the Sprint. Both are left half-finished and the team suffers a loss of morale, discouraged by the setback. Paula is now extremely stressed and frustrated due to not being able to show results to the investors.

How to Overcome this Anti-Pattern

The above example is one I’ve seen countless times with clients I’ve worked with. It can be a difficult position to be in, where a ScrumMaster’s task is to preserve the autonomy of the team while also trying to accommodate the needs and wants of the customer and Product Owner. That said, situations like this should only be occurring extremely rarely – if they become an even semi-regular occurrence, it is critical you work to discover the root cause and why the Product Owner’s needs are changing so frequently. There are various ways of handling this:

• Shorten Sprints – If the Sprint Cycle is two weeks or shorter, we sidestep the problem.
• Stakeholders at Sprint Reviews – If the stakeholders (including the client/customer/end-user) are at the Sprint Review, then they will provide feedback earlier.
• Product Owner works with stakeholders –  if the stakeholders participate in the Backlog Prioritization then they will know what is coming and why.

However it gets resolved, the problem must be addressed and then reflected on if the team is to perform effectively.

Scrum by Example is a narrative-style blog series designed to help people new to Scrum, especially new ScrumMasters. If you are new to the series, we recommend you check out the introduction to learn more about the series and discover other helpful articles.

Mark Levison

Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.