TL; DR: 28+2 Sprint Anti-Patterns from Sprint Stuffing to Gold-Plating
Welcome to the Sprint anti-patterns article from my series on Scrum anti-patterns, covering the three Scrum roles—pardon me: accountabilities—and addressing the contributions of stakeholders and the IT/line management. Moreover, I add 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?
🇩🇪 Zur deutschsprachigen Version des Artikels: 28+2 Sprint Anti-Patterns.
🗳 Update: Join the poll and its lively discussion on LinkedIn.
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 34,000-plus subscribers.
🎓 Join Stefan in one of his upcoming Professional Scrum training classes!
The Purpose of the Sprint
The purpose of the Sprint is clearly described in the Scrum Guide — no guessing is necessary:
Sprints are the heartbeat of Scrum, where ideas are turned into value.
They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.
All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.
Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month. When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase. Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame. Each Sprint may be considered a short project.
Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.
Source: Scrum Guide 2020.
Scrum as a framework is mainly of a tactical nature. The Sprint is about delivering more 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.
Therefore, in my eyes, the actual Sprint is not the place to have meta-level discussions. However, there is plenty of time for these during product discovery, aligning with stakeholders, and refining the Product Backlog.
28 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 can leave the Developers 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 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 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 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.)
- Sprint cancellations without consultation: The Product Owner cancels Sprints without consulting the Scrum 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 rest of the team. Maybe, someone has an idea on 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 live 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.)
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. By 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. Look for Daily Scrum events that support this notion and address the issue during the Sprint Retrospective.)
- 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 by-passing 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.)
- 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, 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 that 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 Nirwana where everything is 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 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 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 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.)
- The maverick & the Sprint Backlog: Someone adds an item to the Sprint Backlog without consulting the Developers first. (The control of the Sprint Backlog by the Developers is at the core of enabling the team to make a forecast. The scope is hence initially untouchable. Changes in the composition of Sprint Backlog are possible, for example, when a critical bug pops up after a Sprint’s start or new work vitaö to accomplishing the Sprint Goal is identified. However, adding such an issue to the Sprint Backlog requires approval by the Developers 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 Developers collectively have the final say. No individual member 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 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. (For example, the Product Owner is too busy to answer the team’s questions or attend the Daily Scrum, or Product Backlog refinement sessions are scarce.)
- No Developer has ever participated in user tests or interviews. Hence there is a lack of understanding of the users’ problems among engineers. (This is the reason why engineers should interview users regularly.)
- The Product Owner presented a too granular user story. Therefore, Developer did not care enough to have a thorough look as the user story seemed ready. (A typical crowding-out effect.)
- 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.)
- 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. (This is just 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 has a devastating effect on stakeholder inclusion, as Scrum events, for example, the Sprint Review, lack a proper cadence, reducing your stakeholder’s willingness to collaborate. So, stop lying to yourself, and address the underlying issues why the team outcome does not meet the Sprint Goal.)
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 to build that trust. Moving people between teams, on the contrary, reflects a project-minded idea of management, rooted in utilization optimization of “human resources” 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 not work if team members are pressed into service. Note: It is not an anti-pattern, though, if Scrum Teams decide to exchange teammates temporarily. It is an established practice that specialists spread knowledge this way or mentor other colleagues. Also, dynamic re-teaming does not constitute an anti-pattern when the members of the involved Scrum Teams decide to do so.)
- 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. 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 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. 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 which 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 achieving 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?
The Replay of the Scrum Sprint Anti-Patterns Webinar
Check out the video of the corresponding webinar:
Note: If the browser will not start the video automatically, click here to watch the replay of the webinar Scrum sprint anti-patterns directly on Youtube.
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 have you observed? Please share those with us in the comments.
📖 Related Posts
Scrum: 20 Sprint Planning Anti-Patterns.
28 Product Backlog Anti-Patterns
21 Sprint Retrospective Anti-Patterns Impeding Scrum Teams
Daily Scrum Anti-Patterns: 24+2 Ways to Improve as a Scrum Team
Download the Scrum Anti-Patterns Guide for free.
✋ Do Not Miss Out: Learn more about Sprint Anti-Patters and Join the 11,000-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.
28+2 Sprint Anti-Patterns Holding Back Scrum Teams was first published on Age-of-Product.com.