27 Sprint Anti-Patterns Holding Back Scrum Teams

The Sprint. Yet another Scrum event where you can find plenty of Sprint anti-patterns to make your life as a Scrum team harder than necessary. Learn how to identify and overcome them.

27 Sprint Anti-Patterns

This list of notorious Sprint anti-patterns applies to all Scrum roles and beyond: the product owner, the development team, the Scrum Master, the Scrum team, as well as stakeholders and the IT management. 

Sprint Anti-Patterns of the Product Owner

• Absent PO: The product owner is absent most of the Sprint and is not available to answer questions of the development team (that creates a micro-waterfall approach for the duration of the Sprint).


• PO Clinging to Tasks: The product owner cannot let go of product backlog items once they become Sprint backlog items. For example, the product owner increases the scope of a user story. Or, he or she changes acceptance criteria once the team accepted the issue into the Sprint backlog. There is a clear line: before a product backlog item turns into a Sprint backlog item the product owner is responsible. However, once it moves from one backlog to the other, the development team becomes responsible. If changes become acute during the Sprint the team will collaboratively decide on how to handle them.


• Inflexible PO: The product owner is not flexible to adjusting acceptance criteria. If the work on a task reveals that the agreed upon acceptance criteria are no longer achievable or waste, the Scrum team needs to adapt to the new reality. Blindly following the original plan violates a core Scrum principle.


• Delaying PO: The product owner does not accept Sprint backlog items once those are finished. Instead, he or she waits until the end of the Sprint. In the Spirit of continuous integration, the product owner should immediately check tasks that meet the acceptance criteria. Otherwise, the product owner will create an artificial queue which will increase the cycle-time. This habit also puts reaching the Sprint goal at risk.


• Misuse of Sprint Cancellation: The product owner cancels Sprints to impose his or her will onto the team. It is the prerogative of the product owner to cancel Sprints. However, the product owner should not do this lightly or without a serious cause. The product owner should also never abort a Sprint without consulting the development team first. Probably, the team has an idea of how to save the Sprint. Lastly, misusing the cancellation privilege also indicates a serious team collaboration issue.


• No Sprint Cancellation: The product owner does not cancel a Sprint whose Sprint goal can no longer be achieved. If the product owner identified a unifying Sprint goal, for example, integrating a new payment method, and the management then abandons that payment method mid-Sprint, continuing working on the Sprint goal would be a waste. In this case, the product owner should cancel the Sprint.

Sprint Anti-Patterns of the Development Team

• No WiP Limit: There is no work in progress limit. The purpose of the Sprint is to deliver a potentially shippable product increment that provides value to either the customers or the organization. This goal requires getting something done by the end of the Sprint. The flow theory suggests that the productivity of a team improves with a work-in-progress (WiP) limit. The WiP limit defines the largest number of tasks a team can work on at the same time. Exceeding this WiP number results in creating extra queues that reduce the throughput of the team. The cycle time, which is the period between starting and finishing a ticket, measures this effect.


• Cherry-Picking: The team cherry-picks work. This effect often overlays with the missing WiP issue. Human beings are motivated by short-term gratifications. It just feels good to solve yet another puzzle from the board, like coding a new task. By comparison to this dopamine fix, checking how someone else solved another problem during code review is less rewarding. Hence you often notice tickets queueing in the code-review-column, for example.


• Board Out-of-Date: The team does not update tickets on the board in time to reflect the current statuses. The board, no matter if it is a physical or digital board, is not only vital for coordinating a team’s work. It is also an integral part of the communication of the Scrum team with its stakeholders. A board that is not up-to-date will impact the trust the stakeholders have in the Scrum team. Deteriorating trust may then cause counter-measures on the side of the stakeholders. The (management) pendulum may swing back toward traditional methods as a consequence. The road back to PRINCE II is paved with abandoned boards.


• Side-Gigs: The team is working on issues that are not visible on the board. While sloppiness is excusable, siphoning off resources, and by-passing the product owner – who is accountable for the Scrum team’s return on investment – is unacceptable. This behavior also signals a massive conflict within the “team.” Given this display of distrust—why didn’t the engineers address this seemingly important issue during the Sprint planning or before—the team is probably a group, rather than a team, anyway.


• Gold-Plating: The team increases the scope of the Sprint by adding unnecessary work to Sprint backlog items. This effect is often referred to as scope-stretching or gold-plating. The development team ignores the original scope agreement with the product owner. For whatever reason, the team enlarges the task without prior consulting of the product owner. This ignorance may result in a questionable allocation of resources. However, there is a simple solution: the developers and the product owner need to talk more often with each other. If the product owner is not yet co-located with the development team, now would be a good moment to reconsider.

Sprint Anti-Patterns of the Scrum Master

• Flow Disruption: The Scrum Master allows stakeholders to disrupt the flow of the development team during the Sprint. There are several possibilities of how stakeholders can interrupt the flow of the team during a Sprint. For example:
• The Scrum Master has a laissez-faire policy as far as access to the development team is concerned. 
• The Scrum Master does not object that the management invites engineers to random meetings as subject matter experts.
• Lastly, the Scrum Master lets either stakeholders or managers turn the daily Scrum into a reporting session. Any of these behaviors will impede the team’s productivity. It is the Scrum Master’s obligation to prevent them from manifesting themselves.


• Lack of Support: The Scrum Master does not support team members that need help with a task. Often, development teams create tasks an engineer can finish within a day. However, if someone struggles with such a task for more than two days without voicing that he or she needs support, the Scrum Master should address the issue. By the way, this is also the reason for marking tasks on a physical board with red dots each day if they do not move to the next column.


• Micro-Management: The Scrum Master does not prevent the product owner—or anyone else—from assigning tasks to engineers. The development team organizes itself without external intervention. And the Scrum Master is the shield of the team in that respect.


• #NoRetro: The Scrum Master does not gather data during the Sprint that supports the team in the upcoming retrospective (this is self-explanatory).

Note: I do not believe that it is the task of the Scrum Master to move tickets on a board. The team members should do this during the stand-up. It is also not the responsibility of the Scrum Master to update an online board so that it reflects the statuses of a corresponding physical board. Lastly, if the team considers a burn-down chart helpful, the team members should also update the chart after the stand-up. 

Sprint Anti-Patterns of the Scrum Team

• The Maverick and the Sprint Backlog: Someone adds an item to the Sprint backlog without consulting the team first. The fixed scope of a Sprint backlog—in the sense of workload—is at the core of enabling the team to make a commitment or forecast. The scope is hence, per se, untouchable during the Sprint. Changes in the composition of the Sprint backlog are possible. For example, when a critical bug pops up after a Sprint’s start. However, adding such an issue to the Sprint backlog requires compensation. Another task of a similar size needs to go back to the product backlog. What all these exceptions have in common is that the Scrum team decides collectively on them. No single teammate can add or remove an item to or from the Sprint backlog.


• Hardening Sprint: The Scrum team decides to have a hardening or clean-up Sprint. That is a simple one: there is no such thing as a hardening sprint in Scrum. The goal of the Sprint is the delivery of a valuable potentially shippable product increment. Often, Scrum teams agree in advance on a standard of what “done” means—also known as DoD or definition of done. Declaring buggy tasks “done” thus violates core principles of the team’s way of collaboration. Hardening Sprints are commonly a sign of a low grade of adoption of Agile principles by the team or the organization. This is probably because the team is not yet cross-functional. Or quality assurance is still handled by a functional, non-Agile silo within the product delivery organization.


• Delivering Y Instead of X: The product owner believes in getting X. The development team is working on Y. This is not merely a result of an inferior product backlog refinement. This anti-pattern indicates that the team failed to create a shared understanding. There are plenty of reasons for this to happen, for example:
• The product owner and the development team members are not talking enough during the Sprint. (The product owner is too busy to answer questions from the team or attend the daily scrum. Or, the team is not co-located, etc.).
• No development team member has ever participated in user tests. There is a lack of understanding the users’ problems among the engineers. (This is the reason why engineers should also interview users regularly).
• The product owner presented too granular of a user story, and no one from the development team cared enough to have a thorough look. The user story seemed ready.
• Probably, the user story was missing acceptance criteria altogether, or existing acceptance criteria missed the problem. No matter the reason, the team should address the issue during the next retrospective.


• No Sense of Urgency: There is no potentially shippable product increment at the end of the Sprint. There was no reason to cancel the Sprint either. It was just an ordinary Sprint. This is a sign that the Scrum team lacks the sense of urgency to deliver at the end of the Sprint. If it is acceptable to fail on delivering value at the end of the Sprint, the whole idea behind Scrum is questioned. Remember, a Scrum team trades a commitment or forecast for inclusion in decision-making, autonomy, and self-organization. Creating a low-grade, time-boxed Kanban and calling it “Scrum” will not honor this deal. Therefore, it is in the best interest of the Scrum team to make each Sprint’s outcome releasable even if the release will not materialize.


• New Kid on the Block: The Scrum team welcomed a new team member during the Sprint. They also forgot to address the issue during Sprint planning, thus ending up overcommitted. While it is acceptable to welcome new teammates during a Sprint, the team needs to account for the resulting onboarding effort during the Sprint planning and adjust its capacity. The new team member should not be a surprise. However, if the newbie turns out to be a surprise, it is, rather, an organizational anti-pattern.


• Variable Sprint Length: The Scrum team extends the Sprint length by a few days to meet the Sprint goal. This is just another way of cooking the Agile books to match a goal or a metric. This is not Agile; it is just inconsequential. Stop lying to yourself, and address the underlying issues that determined why the team outcome did not meet the Sprint goal. Note: I would not consider a deviating Sprint length during the holiday season at the end of the year to be an anti-pattern.

Scrum Anti-Patterns of the IT Management

• All Hands to the Pumps Without Scrum: The management temporarily abandons Scrum in a critical situation. This is a classic manifestation of disbelief in Agile practices, fed by command and control thinking. Most likely, canceling Sprints and gathering the Scrum teams would also solve the issue at hand.


• Reassigning Team Members: The management regularly assigns team members of one Scrum team to another team. Scrum can only live up to its potential if the team members can build trust among each other. The longevity of teams is hence essential. Moving people between teams, on the contrary, reflects a project-minded idea of management. It also ignores the preferred team building practice that Scrum teams should find themselves. All members need to be voluntarily on a team. Scrum rarely works if team members are pressed into service. Note: It is not an anti-pattern, though, if two teams decide to exchange teammates temporarily. It is an established practice that specialists spread knowledge this way or mentor other colleagues. 


• Special Forces: A manager assigns specific tasks directly to engineers, thus bypassing the product owner. Alternatively, the manager removes an engineer from a team to work on such a task. This behavior does not only violate core Scrum principles. It also indicates that the manager cannot let go of command and control practices. He or she continues to micromanage subordinates although a Scrum team could accomplish the task in a self-organized manner. This behavior demonstrates a level of ignorance that may require support from a higher management level to deal with.

Sprint Anti-Patterns of Stakeholders

• Pitching Developers: The stakeholders try to sneak in small tasks by pitching them directly to developers (Nice try #1).


• Everything’s a Bug: The stakeholders try to speed up delivery by relabeling their tasks are ‘serious bugs.’ Nice try #2. A special case is an “express lane” for bug fixes and other urgent issues. Every stakeholder will try and make his or her tasks eligible for that express lane.


• Disrupting the Flow: The stakeholders disrupt the flow of the Scrum team (see above, Scrum Master section).

Conclusion: Scrum Sprint Anti-Patterns

Although the Sprint itself is just a time-box, there are plenty of Sprint anti-patterns to observe. A lot of them are easily fixed by the Scrum team. Other Sprint anti-patterns, however, point to organizational issues that probably will require more than a retrospective to change.

What Sprint anti-patterns are missing? Please share with us in the comments.

Post Scriptum:

Download the ‘Scrum Anti-Patterns Guide’ with over 100 Scrum anti-patterns here.