TL; DR: 27 Sprint Anti-Patterns Holding Back Scrum Teams
Welcome to Sprint anti-patterns article from our series on Scrum anti-patterns, covering not just the three Scrum roles, but also the stakeholders as well as the IT management.
Do you want to get this article in your inbox? You can sign up here and join 25k other subscribers.
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 itself, 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. (As the Sprint Backlog is emergent and new work may be identified as necessary to achieve the Sprint Goal, this attitude might leave the Development Team in the dark, risking the accomplishment of the Sprint Goal.)
- PO clinging to tasks: The Product Owner cannot let go of Product Backlog items once they become part of the Sprint Backlog. For example, the Product Owner increases the scope of a requirement. 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 part of the Sprint Backlog, 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 adjust 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 core Scrum principles.)
- Delaying PO: The Product Owner does not accept items from the Sprint Backlog once those are finished. Instead, he or she waits until the end of the Sprint. (The Product Owner should immediately check tasks that meet the acceptance criteria. Otherwise, the Product Owner will create an artificial queue within the Sprint, which will unnecessarily increase the cycle-time. This habit puts also 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 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 consider canceling the 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 the customers and thus to the organization. This goal requires focused work to accomplish the work deemed necessary to meet the Sprint Goal 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 maximum number of tasks a development team can work on at the same time. Exceeding this WiP number results in creating additional queues that consequently reduce the overall throughput of the Development Team. The cycle time, which is the period between starting and finishing a ticket, measures this effect.)
- Cherry-picking: The Development 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, here: 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 queuing in the code-review-column, for example. It is also a sign that the Development Team is not yet fully self-organizing. Look also for Daily Scrum events that support this notion, and address the issue during the Sprint Retrospective.)
- Board out-of-date: The team does not update tickets on the Sprint board in time to reflect the current statuses. (The Sprint board, no matter if it is a physical or digital board, is not only vital for coordinating the Development 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 Development 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 return on investment the Development Team is creating—is unacceptable. This behavior also signals a substantial 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 Development Team is probably rather a group anyway.)
- Gold-plating: The Development Team increases the scope of the Sprint by adding unnecessary work to Product Backlog items of the Sprint Backlog. (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, creating a shared understanding from product vision down to the individual Product Backlog item, thus improving the trust level. If the Product Owner is not yet co-located with the Development Team, now would be the right moment to reconsider.)
Sprint Anti-patterns of the Scrum Master
- Flow disruption: The Scrum Master allows stakeholders to disrupt the flow of the Scrum Team during the Sprint. There are several possibilities for how stakeholders can interrupt the flow of the team during a sprint. Any of the examples will impede the team’s productivity and might endanger the Sprint goal. The Scrum Master must prevent them from manifesting themselves:
- The Scrum Master has a laissez-faire policy as far as access to the Development team is concerned. Particularly, he or she is not educating stakeholders on the negative impact of disruptions and how those may endanger the accomplishment of the Sprint goal.
- The Scrum Master does not oppose line managers taking team members off the team assigning other tasks.
- Lastly, the Scrum Master allows that either stakeholders or managers turn the Daily Scrum into a reporting session. This behavior will impede the Development Team’s productivity by undermining its self-organization, reintroducing command & control through the backdoor.)
- 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 job for more than two days without voicing that he or she needs support, the Scrum Master should address the issue and offer his or her support. By the way, this is also the reason for marking tasks on a physical Sprint board with red dots each day if tasks do not move to the next column. (In other words: we are tracking the work item age.)
- 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: There is no Retrospective as the team believes there is nothing to improve. (There is no such thing as an agile Nirvana where everything is just perfect. As people say: becoming agile is a journey, not a destination, and there is always something to improve.)
Note: I do not believe that it is the task of the Scrum Master to move tickets on a Sprint board. The Development Team members should do this during the Daily Scrum if they consider this to be helpful. 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 Development Team considers a burn-down chart helpful, the team members should also update the chart themselves. #justsaying #scrummasterisnotascribeorsecretary
Sprint Anti-patterns of the Scrum Team
- The maverick & the Sprint Backlog: Someone adds an item to the Sprint Backlog without consulting the Development Team first. (The control of the Sprint Backlog by the Development Team—in the sense of workload—is at the core of enabling the team to make a forecast. The scope is hence per se untouchable during the Sprint. Changes in the composition of 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 approval by the Development Team and probably a level of compensation. Another task of a similar size might need to go back to the Product Backlog. All these exceptions have in common that the Development Team has the final say collectively. No single teammate of the Scrum team can add or remove an item to or from the Sprint Backlog single-handedly.)
- 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. For that purpose, the Development Team creates a definition of “Done” to ensure that everyone understands the required quality level for a product Increment to be “shippable” to customers. Declaring buggy tasks “done” thus violates this core Scrum principle 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 with the product delivery organization. Alternatively, the Development Team might have felt pressured to deliver to meet an (arbitrary) deadline, and they decided to cut corners by reducing quality. No matter the reason, in such a situation, there is plenty of work for the Scrum Master to accomplish.)
- 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 Scrum Team failed to create a shared understanding. There are plenty of reasons for this to happen, just to list a few:
- 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 or customer interviews. There is a lack of understanding of the users’ problems among engineers. (This is the reason why engineers should also interview users regularly.)
- The Product Owner presented a too granular 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 Scrum 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 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 overextended. (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 why the team outcome does 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.)
Sprint Anti-patterns of the IT Management
- All hands to the pumps w/o Scrum: The management temporarily abandons Scrum in a critical situation. (This is a classic manifestation of disbelief in agile practices, fed by command & 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 Scrum 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, rooted in utilization optimization at the team member level of the industrial paradigm. It also ignores the preferred team-building practice that Scrum Teams should select themselves. All members need to be voluntarily on a team. Scrum does rarely work if team members are pressed into service. Note: It is not an anti-pattern, though, if the Scrum 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 and ignoring the Development Team’s prerogative to self-organize. 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 for the Scrum Master 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. In my experience, 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
Although the Sprint itself is just a container for all other Scrum events, there are plenty of Sprint anti-patterns to observe. A lot of them are easy to fix by the Scrum Team or the Scrum Master. However, some sprint anti-patterns point at organizational issues that probably will require more than a Sprint Retrospective to change.
What Sprint anti-patterns are missing? Please share with us in the comments.
✋ Do Not Miss Out: Join the 6,800-plus Strong ‘Hands-on Agile’ Slack Team
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
Related Posts
Scrum: 19 Sprint Planning Anti-Patterns.