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
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.” 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.
How to Learn More
If you or your organization are new to Scrum and want to make implementation an empowering process and avoid Scrum Anti-Patterns like the one above, Mark coaches people how to do this in our Certified ScrumMaster courses, where you can learn how to be effective in the ScrumMaster role, supporting and growing autonomous and high-performing teams. If the above is at all a familiar experience to you, we would be delighted to help you grow your team to be the best it can be.
Scrum by Example is a narrative-style blog series designed to help people in their first few years of 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.
» Next Scrum By Example – How to Deal with Bad User Stories as a ScrumMaster
See all blog posts