Sprint Anti-Patterns

Welcome to Sprint anti-patterns! This article covers the three Scrum accountabilities (formerly roles) and addresses interferences of stakeholders and IT/line management with this crucial Scrum event. 

Moreover, I added some food for thought. For example, could a month-long Sprint be too short for accomplishing something meaningful? And if so, what are the consequences?

The Purpose of the Sprint

The purpose of the Sprint is clearly described in the Scrum Guide — no guessing is necessary:

• Sprints transform hypotheses into value.
• They are consistent, fixed-length events of one month or less, with new Sprints starting immediately after the previous one ends.
• Every activity required to achieve the Product Goal, such as Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, occurs within Sprints.
• Sprints foster predictability by inspecting and adapting progress towards a Product Goal at least every calendar month.
• If a Sprint is too long, the market may invalidate a Sprint Goal, increasing complexity and risk.
• Shorter Sprints, similar to short projects, promote more learning cycles and limit the risk of cost and effort to a briefer time frame. 

Source: Scrum Guide 2020.

Scrum as a framework is mainly of a tactical nature. The Sprint is about delivering value to customers, guided by the Sprint Goal, based on previously explored and validated hypotheses. It is all about getting things out of the door, thus closing the feedback loop and starting another round of inspection and adaption. Besides working on accomplishing the Sprint Goal, a Scrum Team also allocates time to product discovery, aligning with stakeholders, and refining the Product Backlog.

29 Sprint Anti-Patterns

This list of notorious Sprint Anti-Patterns applies to all Scrum roles and beyond the Product Owner, the Developers, the Scrum Master, the Scrum Team itself, as well as stakeholders and the IT/line 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 Developers. (As the Sprint Backlog is emergent and the Developers may identify necessary new work or the scope of previously identified work may need to be adjusted, the Product Owner’s absence will likely leave the Developers in the dark, creating undone work that requires a decision on how to move on. No matter the reasons for the Product Owner’s absence, it displays the team’s value creation, putting the accomplishment of the Sprint Goal at risk. It is an expensive Sprint Backlog anti-pattern.)
• 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 work item or changes acceptance criteria once the Developers select this Product Backlog item for the Sprint Backlog. (There is a clear line: before a Product Backlog item becomes part of the Sprint Backlog, the Product Owner is responsible. However, once it moves from one backlog to the other, the Developers become responsible. If changes become acute during the Sprint, the team will collaboratively decide 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 useful, 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 provide feedback on work items from the Sprint Backlog once those are done. Instead, they wait until the end of the Sprint. (The Product Owner should immediately inspect Product Backlog items that meet the acceptance criteria. Otherwise, the Product Owner will create an artificial queue within the Sprint, unnecessarily increasing the cycle time. This habit also puts reaching the Sprint Goal at risk. Note: Inspecting Product Backlog items does not equal some sort of work acceptance or quality gate. There is no such thing in Scrum. Once a Product Backlog item meets the Definition of Done, it can be released into the hands of users.)
• Sprint stuffing: The Developers accomplished the Sprint Goal early, and the Product Owner is pushing them hard to accept new work from the Product Backlog to fill the “void.” (The Scrum Team decided collaboratively on the Sprint Goal, and the Developers committed to delivering. Consequently, it is the prerogative of the Developers to decide on the composition of the Sprint Backlog. Should they manage to accomplish the Sprint Goal before the Sprint’s end, it is their sole decision to fill the remaining time. Accepting new work from the Product Backlog may be one way of filling the remaining Sprint time-box. This also applies to refactoring parts of the tech stack, exploring new technology that might be useful, fixing some bugs, or sharing knowledge with fellow teammates. Scrum is not in the business of maximizing the utilization rates of team members. Achieving the Sprint Goal is sufficient as it is the most valuable addition to the product the team can accomplish during the Sprint. However, should the team regularly deliver the Sprint Goal early, the Scrum Team may want to inspect that behavior during a Retrospective. The team may be playing safe, whatever the reason. In this case, the urge of the Product Owner to stuff the Sprint Backlog is less of an anti-pattern but rather an expression that the team needs to address the elephant in the room.)
• Sprint cancellations without consultation: The Product Owner cancels Sprints without consulting the Scrum Team. (Technically, it is the prerogative of the Product Owner to cancel Sprints. However, the Product Owner should not do this without a serious cause. Moreover, the Product Owner should never abort a Sprint without consulting the rest of the Scrum Team. Maybe, someone knows how to save the Sprint Goal, provided it is still useful? Misusing the cancellation privilege indicates a serious team collaboration issue and a lack of commitment to living Scrum Values.)
• No Sprint cancellation: The Product Owner does not cancel a Sprint whose Sprint Goal can no longer be achieved or has become obsolete. (If the Scrum Team identified a unifying Sprint Goal, for example, integrating a new payment method, and the management then abandons that functionality mid-Sprint, continuing working on the Sprint Goal would be wasteful. In such a case of obsolescence, the Product Owner has to consider canceling the Sprint. If the Product Owner fails to do so, continuing the work would create waste while raking up significant opportunity costs. Moreover, nothing is more frustrating than working on something no one will use while squandering valuable time. By the way, the fact that the Developers receive payment for the wasted effort does not equalize the issue.)

Anti-Patterns of the Developers

• 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 necessary work to meet the Sprint Goal by the end of the Sprint. The flow theory suggests that a team's productivity improves with a work-in-progress (WiP) limit. The WiP limit defines the maximum number of tasks the Developers can work on simultaneously. Exceeding this WiP number creates additional queues that consequently reduce the overall throughput of the Developers. The cycle time—the period between starting and finishing a ticket—measures this effect.)
• Cherry-picking: The Developers cherry-pick 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. In comparison to this dopamine fix, checking how someone else solved another problem during code review is less rewarding. Hence, you may notice tickets queueing in the code-review column, for example. It is also a sign that the Developers are not yet fully self-organizing. Conversely, mature Scrum Teams have a shared understanding of the team goals and prioritize work that benefits the team’s objectives over individual interests. They understand the importance of finishing tasks and adhere to the agreed-upon Definition of Done.)
• Board out-of-date: The Developers do 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 Developers’ 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 confidence may then cause counter-measures on the side of the stakeholders. Consequently, the (management) pendulum may swing back toward traditional methods. The road back to PRINCE II is paved with abandoned boards.)
• Side-gigs: The Developers are working on issues that are not visible on the board. (While sloppiness is excusable, siphoning off resources and bypassing the Product Owner—who is accountable for the return on investment the Scrum 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 Developers are probably rather a group than a team anyway. However, there might be an exception that proves this rule: Suppose the Scrum Team’s Product Owner has a dominant personality and relentlessly pushes to ship as many new features as possible. Moreover, the management supports the Product Owners in their approach as they consider this an excellent way to maximize output. Consequently, there is little or no time to attend to refactoring or bug fixing unless the Developers tackle these jobs under the radar. In this situation, I would have sympathy for the approach as a stop-gap measure before solving the underlying challenge of the pushy Product Owner.)
• Gold-plating: The Developers increase the scope of the Sprint by adding unnecessary work to the Product Backlog items of the Sprint Backlog. (This effect is often referred to as scope-stretching or gold-plating. The Developers ignore 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 development time. However, there is a simple solution: the Developers and the Product Owner need to talk more often, 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 Developers, now would be the right moment to reconsider. Alternatively, a distributed Scrum Team may invest more time in how to communicate synchronously and asynchronously best to improve its level of collaboration and alignment.)

  

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 team’s flow during a Sprint. Any of the following examples will impede the team’s productivity and might endanger accomplishing the Sprint Goal:
  • The Scrum Master has a laissez-faire policy as far as access to the Developers is concerned. Notably, they are not educating stakeholders on the negative impact of disruptions and how those may endanger accomplishing the Sprint Goal. Note: I do not advocate that Scrum Masters shall restrict stakeholders’ access to team members in general.
  • The Scrum Master does not oppose line managers taking team members off the Scrum Team, and assigning them to other tasks.
  • The Scrum Master does not oppose line managers adding members to the Scrum Team without prior consultation of the team members. (Preferably, the Scrum Team members should decide who is joining the team.)
  • Lastly, the Scrum Master allows stakeholders or managers to turn the Daily Scrum into a reporting session. (This behavior will impede the Developer’s productivity by undermining their self-management while reintroducing command & control through the backdoor.)
• Lack of support: The Scrum Master does not support team members who need help. Often, Developers create tasks an engineer can finish within a day during their planning sessions. However, if someone struggles with such a job for more than two days without voicing that they need support, the Scrum Master should address the issue and offer their support. Making this issue visible is also the reason for marking tasks on Sprint boards with red dots each day if work items 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 Developers directly. (The Developers organize themselves without external intervention. The Scrum Master is the first line of defense of the Developers in that respect.)
• #NoRetro: There is no Retrospective as the team believes there is nothing to improve, and the Scrum Master accepts this notion. (There is no such thing as an agile Nirvana where everything is perfect. As people say: becoming agile is a journey, not a destination, and there is always something to improve. Retrospectives are a critical part of Scrum’s principle of continuous improvement which, for example, the Scrum Value of Commitment reflects. A formalized event like the Retrospective allows the Scrum Team to focus exactly on this challenge.) 

Note: I do not believe that it is the task of the Scrum Master to maintain a Sprint board, for example, by moving tickets. The Developers should do this during the Daily Scrum if they consider this 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 Developers consider a burn-down chart helpful, they should also update the chart themselves. #justsaying #scrummasterisnotascribeorsecretary

Sprint Anti-Patterns of the Scrum Team

• Not having a Sprint Goal: The Product Owner proposes a direction that resembles a random assortment of tasks, providing no cohesion. Consequently, the Scrum Team does not create a Sprint goal. (If this is the natural way of finishing your Sprint Planning, you probably have outlived the usefulness of Scrum as a product development framework. Depending on the maturity of your product, Kanban may prove to be a better solution. Otherwise, the randomness may signal a weak Product Owner who listens too much to stakeholders instead of ordering the Product Backlog appropriately.)
• Not delivering the Sprint Goal: The Scrum Team misses the Sprint Goal more often than delivering it. (We are not getting paid to practice Scrum. We are paid to solve our customers’ problems within the given constraints, allowing our organization to build a sustainable business in the process. Given Scrum’s delivery focus and tactical nature, agreeing on a Sprint Goal and then delivering it is the most critical contribution of the Scrum Team. While there may be many situations where the team cannot accomplish the Sprint Goal occasionally, for example, because of technical issues, skill deficits, and the complexity and uncertainty of life itself, this failure should be the exception, not the rule. If it is acceptable to fail to deliver 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.)
• The Maverick and the Sprint Backlog: Someone adds an item to the Sprint Backlog without consulting the Developers first. (Having Developers control their own Sprint Backlog helps them forecast. They may add to the Sprint Backlog, for example, when they discover they need to fix a critical bug after the Sprint’s start or when they identify new work that is vital to achieving their Sprint Goal. The Developers need to be the ones to decide they will take on this work in the Sprint since they often have to take other work off the Sprint Backlog in order to make room for the new work. Only the Developers have the knowledge to make these decisions, and the decisions are theirs alone.)
• 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 Sprint’s goal is to deliver a valuable, potentially shippable Product Increment. For that purpose, the Scrum 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 Scrum 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 Developers 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 Developers are 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 Developers are not talking enough during the Sprint. Maybe, the Product Owner is too busy to answer the team's questions or attend the Daily Scrum. Alternatively, Product Backlog refinement sessions during the Sprint are inadequate.
  • Developers don’t participate in user conversations with customers or users, so they lack understanding of the users' problems. Developers should talk to users regularly to better understand their needs.
  • The Product Owner presented a too-granular Product Backlog item instead of seeking a discussion with the Developers about the Why and What during refinement. The Developers give the Product Owner what they asked for, not what the user really needed. 
  • Probably, the Product Backlog item was missing acceptance criteria altogether, or existing acceptance criteria missed the problem. 
• New kid on the block: The Scrum Team welcomed a new team member during the Sprint. Unfortunately, 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 an organizational anti-pattern.)
• Variable Sprint length: The Scrum Team extends the Sprint length by a few days to meet the Sprint Goal. (Generally, if the Sprint length needs to change, the Scrum Team inspects and adapts its working practices during the Retrospective. However, during a Sprint, and contrary to all other Scrum events, the Sprint timebox is fixed. Consequently, changing it in a last-ditch effort to realize a Sprint Goal that is out of reach is another way of cooking the agile books to match a goal or metric. Extending the Sprint length is not agile; it is just inconsequential. Additionally, it devastates stakeholder inclusion, as Scrum events, for example, the Sprint Review, lack a proper cadence, reducing your stakeholders' willingness to collaborate.)

Sprint Anti-Patterns of the Line Managers

• 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 and a bias for action to feel “in control” of the situation on their side. Most likely, canceling Sprints and gathering the Scrum Teams would also solve the issue.) 
• 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 Scrum Teams has proven beneficial in building that trust. Moving people between teams, on the contrary, reflects a project-minded idea of management rooted in the utilization optimization of “human resources” from the ages of the industrial paradigm. Also, it ignores the preferred team-building practice that Scrum Teams should select themselves. All members need to be voluntarily on a team. Scrum does not work if team members are pressed into service. However, it is not an anti-pattern if Scrum Teams decide to exchange teammates temporarily. It is an established practice where specialists spread knowledge this way or mentor colleagues. ) 
• Special forces: A manager assigns specific tasks directly to Developers, thus bypassing the Product Owner and ignoring the Developer’s self-organization prerogative. Alternatively, the manager removes a Developer 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. They continue to micromanage subordinates, although a Scrum Team could accomplish the task self-organized. Common reasons for this behavior are trust issues, control orientation, and probably a lack of understanding of the details of Scrum.)

Sprint Anti-Patterns of the Stakeholders

• (Regular) emergency work: Someone in your organization has sold a non-existing feature or functionality to a customer to close a deal, probably already including delivery dates and contractual penalties in the case of non-delivery. Now, they want the Scrum Team to focus on delivering this item. (There might be moments where this outside intervention in the Scrum process may be unfortunate but acceptable, such as an existential business threat, regulatory or legal compliance, a critical bug fix or security threat, or a significant market opportunity. However, the more concerning issue here is the prospect of this behavior becoming a regularity. If the leadership does not acknowledge the exceptionality of the situation, it may derail using Scrum in the organization.)
• Pitching Developers: The stakeholders try to sneak in small tasks by pitching them directly to Developers. (Nice try, #1. However, all suggestions for the future allocation of the Scrum Team’s time compete with each other, and the Product Owner is the referee in this process.)
• Everything’s a bug: The stakeholders try to speed up delivery by relabeling their tasks are ‘serious bugs.’ (Nice try, #2. A particular case is an “express lane” for bug fixes and other urgent issues that some Scrum teams establish. In my experience, every stakeholder will try and make their tasks eligible for that express lane.)

Food for Thought

There are some issues that are worthwhile considering as a Scrum Team regarding the Sprint:

What if a month-long Sprint is still too short? There are areas where a month-long Sprint may prove to be too short, for example, in hardware development or machine learning when training new models. Would it be okay to extend the length of a Sprint? Or would such a situation signal abandoning Scrum altogether and moving to alternatives such as Shape Up?

Dying in beauty? Is there a moment when circumstances become so desperate that abandoning Sprints is a valid option? For example, think of a startup running out of cash, and the only way to survive is to achieve a particular milestone defined by a prospective new investor. Would that be a moment when to abandon Scrum’s rigorous process to have a fighting chance?

Conclusion

Although the Sprint itself is just a container for all other Scrum events, there are plenty of Sprint anti-patterns to observe. Many of them are easy to fix by the Scrum Team or the Scrum Master when empathizing with the stakeholders’ situation and asking yourself: How did I contribute to this situation in the past? 

What Sprint anti-patterns have you observed? Please share those with us in the comments.