TL; DR: Missing Sprint Goals
Do you excel in the art of setting unattainable, imposed, or plain non-existing Sprint Goals? In other words, are you good at missing Sprint Goals with regularity? If not, don’t worry; help is on the way!
In this article, we’ll explore how to consistently miss the mark. For example, enjoy the thrill of cherry-picking unrelated backlog items and defining success by sheer output, not outcome. Countless Scrum Teams have thoroughly tested all suggestions. They are ideally suited for teams who love the challenge of aimlessly wandering through Sprints!
📖 Preorder the Scrum Anti-Patterns Guide book now for delivery in January 2024!
🗞️ Exclusively on my Substack Newsletter: Daily Scrum Anti-Patterns — An Excerpt from the Scrum Anti-Patterns Guide (6).
🥇 The most popular discussion on LinkedIn last week was: Velocity, accurate predictions — all lies we tell ourselves. 🤬
🇩🇪 Zur deutschsprachigen Version des Artikels: Warum erfolgreich sein, wenn man scheitern kann? Ein Leitfaden zum Verfehlen von Sprint-Zielen.
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 49,000-plus subscribers.
🎓 Join Stefan in one of his upcoming Professional Scrum training classes!
📅 Join 200-plus peers on December 6, 2023: Hands-on Agile #57: Humble Planning: How To Make Your Plans Suck Less w/ Maarten Dalmijn.
The Essence and Inherent Importance of the Sprint Goal
Before we indulge ourselves in missing Sprint Goals and, thus, failing core responsibilities as a Scrum Team, let’s revisit the original ideas behind Sprint Goals:
The Sprint Goal is a Scrum team’s single objective for Sprint, delivering the most valuable result from the customers’ and the organization’s perspective.
It informs the composition of the Sprint Backlog and becomes a part of it, thus acting as a beacon that guides the Developers during the Sprint. Moreover, it is instrumental to creating the Sprint plan, having a successful Daily Scrum, and collaborating and supporting each other as a Scrum team.
Also, the Sprint Goal helps the Scrum team to identify whether their work was successful: did we accomplish the goal at the end of the Sprint? In that respect, it separates a few weeks of working on “stuff” from experiencing the satisfaction and joy of being a successful Scrum team, delivering value to customers and the organization.
The Sprint Goal thus supports a Scrum team—and its organization—to move from an industrial paradigm-driven output orientation, the proverbial feature factory, to an outcome-based approach to solving your customers’ most valuable problem every Sprint.
This change of perspective has a far-reaching consequence: every Sprint, the Scrum team strives to accomplish the Sprint Goal, which is different from maximizing the output in the form of work hours or the number of work items.
The process of forming a Sprint Goal begins with Sprint Planning, when the Developers, the Product Owner, and the Scrum Master come together to decide on the next steps for building, ensuring the delivery of maximum value to customers in the forthcoming Sprint.
How to Create Sprint Goals
Initially, the Product Owner highlights the overarching Product Goal and outlines the business aim for the new Sprint. Using this as a foundation, the Scrum team collaboratively establishes the Sprint Goal, considering various factors such as:
- Team availability during the Sprint.
- Any changes in team composition, including new members joining or existing members departing.
- The desired quality level as specified in the Definition of Done.
- The team’s proficiency with the necessary technology.
- The availability of required tools.
- Dependencies to other teams or suppliers.
- Specific governance requirements that need to be met.
- The necessity to manage daily operations, like maintaining the product’s functionality, and how this impacts team capacity.
Following this, the Developers pledge their commitment to the Sprint Goal. It’s important to understand that this commitment isn’t to a fixed amount of work, such as the tasks listed in the Sprint Backlog after Sprint Planning. Scrum focuses on outcomes rather than outputs.
In response, the Developers then project the work needed to reach the Sprint Goal. They do this by selecting items from the Product Backlog to include in the Sprint Backlog. If additional, previously unidentified tasks are necessary to achieve the Sprint Goal, they add these to the Sprint Backlog.
Moreover, the Developers form an initial plan for accomplishing their projection. Doing so for the first two or three days is advisable, as the team will begin gathering insights once the work commences. Detailed planning for the entire Sprint at this stage would be counterproductive.
Ten Sure-Fire Ways to Miss Your Sprint Goals
Here are my top ten approaches to missing Sprint Goals to ensure you will fail your stakeholders every single Sprint:
- No Visualization of Progress: The Developers cannot promptly assess whether they are on track to achieve the Sprint Goal. This lack of clarity often stems from inadequate tracking and visualization of progress. The Daily Scrum addresses this by ensuring the team is aligned and on track, with adjustments made as needed to the plan or Sprint Backlog. Without a clear understanding of their progress, Developers are less likely to meet the Sprint Goal, as success in Sprints builds from growing confidence over time, not last-minute efforts.
- Kanban through the Backdoor: The Scrum team consistently takes on too many tasks, leading to a regular overflow of unfinished work into the next Sprint—without further consideration or inspection. This practice, especially when 30 to 40 percent of tasks routinely spill over, indicates a shift towards a ‘time-boxed Kanban’ style rather than adhering to Scrum principles. This habitual spillover suggests a need to reassess and realign the team’s approach to fit the Scrum framework better.
- Scope Stretching or Gold-Plating: The Developers expand the scope of the Sprint beyond the agreed-upon Sprint Goal by adding extra, unnecessary work to the Product Backlog items in the Sprint Backlog. This issue arises when Developers disregard the original scope agreement with the Product Owner and unilaterally decide to enhance tasks without consultation. This behavior can lead to questionable allocation of development time, as it shifts focus away from the agreed priorities and goals, potentially impacting the team’s ability to deliver value effectively. This anti-pattern may reflect a disconnect between the Developers and the Product Owner, undermining the collaborative spirit essential for proper Scrum implementation.
- Cherry-Picking Product Backlog Items: The Developers select Product Backlog items unrelated to the Sprint Goal, resulting in a disorganized assortment of tasks. This issue often arises from a lack of a clear Sprint Goal or a goal that is too vague or simply a task list. Factors contributing to this pattern may include the need to address urgent technical issues, a desire to pursue new learning opportunities or disagreement with the product direction. If these scenarios don’t apply, it raises concerns about the team’s unity and effectiveness, suggesting they might operate more as individuals than as a cohesive Scrum team.
- The Imposed Sprint Goal: In this case, the Sprint Goal is not a collective decision of the Scrum team but rather dictated by an individual, often a dominant Product Owner or lead engineer. This scenario often unfolds in environments lacking psychological safety, where team members, despite foreseeing potential failure, remain silent and unopposed to the imposition. This pattern reflects a deeper issue within the team, signaling a departure from the core Scrum Values. Some team members may have resigned to the status quo, losing interest in continuous improvement and collaboration. In such cases, the team might be more accurately described as a group of individuals working in parallel, more focused on their paychecks than genuine teamwork and shared success.
- The Overly Ambitious Sprint Goal: In this scenario, Scrum teams, often new ones, set unattainably high Sprint Goals, leading to an oversized Sprint Backlog and inevitable underdelivery at Sprint’s end. This issue typically decreases as the team gains experience and better understands their capacity and customer problems. Mature Scrum teams learn to align their capabilities with their aspirations, ensuring they deliver the best possible value to customers and the organization.
- Lack of Focus: The organization treats the Scrum team as a jack-of-all-trades unit, burdening them with various unrelated tasks hampering the team’s ability to formulate a cohesive Sprint Goal. Such a scenario is counterproductive to Scrum’s essence, which is about tackling complex problems through self-managing, autonomous teams and minimizing development risks. While Scrum excels at achieving specific objectives, its effectiveness diminishes when external stakeholders dictate the team’s workload in detail. This approach undermines Scrum’s core principle of focused, goal-oriented work and risks turning the team into a reactive rather than proactive unit.
- No Space for Non-Sprint Goal-Related Work: The Scrum team focuses solely on the Sprint Goal, overlooking other critical tasks such as customer support and organizational demands. Effective Scrum practice requires balancing the Sprint Goal with responding to unexpected, yet crucial, issues. Ignoring significant problems, like a critical bug or a malfunctioning payment system, just because they fall outside the Sprint Goal can quickly erode stakeholder trust. Scrum is about adaptability and responding to new challenges, not rigidly adhering to an initial plan, turning the Sprint into a Waterfall-ish time box.
- Regularly Not Delivering the Sprint Goal: Some Scrum teams fail to meet their Sprint Goals with the precision of a Swiss clockwork. This ongoing issue undermines Scrum’s core objective: solving customer problems effectively and aiding organizational sustainability. Scrum’s usefulness relies on meeting the Sprint Goal, which should be the norm, not the exception. Continual failures, whether due to technical issues, skill shortages, or unforeseen complexities, question the validity of using Scrum. A successful application of Scrum involves a commitment to goals in return for decision-making autonomy and self-organization, not merely mimicking Kanban under the guise of Scrum.
- No Sprint Goal: Here, the Product Owner presents a disparate collection of tasks, lacking a cohesive objective, which leaves the Scrum team without clear direction. This situation indicates a potential misapplication of Scrum principles, suggesting that shifting to a more flow-based system like Kanban might better suit the team’s needs. Typically, this pattern arises when a Product Owner is either overwhelmed by stakeholder demands or lacks the experience to align tasks effectively with the team’s overall Product Goal.
Food for Thought — Missing Sprint Goals
Consider the following questions to help your teams and your organization to avoid missing Sprint Goal and embrace agility fully:
- Are there other underlying team dynamics or organizational practices contributing to these anti-patterns?
- What are the long-term impacts of these anti-patterns on the overall health and productivity of the Scrum team and its standing within the organization?
- How can the Scrum framework be adapted or reinforced to mitigate these anti-patterns, especially in diverse or rapidly changing work environments?
Conclusion
These ten Sprint Goal anti-patterns highlight various challenges that Scrum teams may face, from minor inefficiencies to major dysfunctions that can significantly undermine Scrum principles and, thus, the team’s effectiveness. Addressing these issues requires a nuanced understanding of team dynamics, organizational culture, and commitment to continuous improvement and adherence to Scrum values. By recognizing and proactively addressing these anti-patterns, Scrum teams can enhance their ability to deliver value effectively and sustainably.
What anti-patterns have you encountered, and how did you counter missing Sprint Goals? Please share your experience in the comments.
Pre-Order the Scrum Anti-Patterns Guide Book on Amazon Now!
PS: The Scrum Anti-Patterns Guide book is now available for pre-order: Check out US, UK, and DE. Click the banner to be directed to your local Amazon store. (Handled by Genius Link; includes an affiliate link at no cost to you.)
Missing Sprint Goals — Related Articles
No Sprint Goal, No Cohesion, No Collaboration — Making Your Scrum Work #26
Nine Sprint Goal Principles to Get Your Scrum Team Going
Scrum: 20 Sprint Planning Anti-Patterns
Download the Scrum Anti-Patterns Guide for free
📅 Scrum Training Classes, Workshops, and Events
Learn more about how to avoid missing Sprint Goals with our Scrum training classes, workshops, and events. You can secure your seat directly by following the corresponding link in the table below:
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.
✋ Do Not Miss Out and Learn more about How to Avoid Missing Sprint Goals — Join the 19,000-plus Strong ‘Hands-on Agile’ Slack Community
I invite you to join the “Hands-on Agile” Slack Community and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join 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.
Support your team’s efforts to avoid missing Sprint Goals by pointing to the free Scrum Anti-Patterns Guide:
I find the way most teams are taught (coached) doesn’t lend itself well to attaining Sprint Goals. Here’s what I see. At best a Product Owner defines a Product Goal (actually I rarely see this…but for argument let’s say that happens). By talking to various stakeholders/users/etc. a product backlog is built. In Sprint Planning the PO suggests what they’d like to see implemented from the Backlog, that stuff is brought into Sprint Planning and the Sprint Backlog is created. THEN, the teams steps back, looks at the Sprint Backlog and creates a Sprint Goal…which probably has little connection to the Product Goal because the PO’s, and team’s, primary focus is on the Backlog. Do whatever you can to complete the work in the Backlog!! They lose sight of the Product Goal.
I’d much rather see teams create a Product Goal that covers 3-4 months, then immediately create their Sprint Goals that will help them achieve that Product Goal.
Don’t wait for Sprint Planning. Then, when Sprint Planning comes around, choose from the Backlog those items that will help them achieve the Sprint Goal. If those items don’t exist, or there aren’t enough of them, they either need to gather them (discussions with stakeholders/users/etc.) or change their Product Goal because they’ve just received feedback that it’s probably changed (if stakeholders/users/etc. can’t tell them the what they want that will help them achieve the Sprint Goal, because that’s what will help them achieve the Product Goal…then the Product Goal needs to be reviewed). All too often teams choose from the top of the Backlog then make up some for of Sprint Goal that encapsulates what they’ve just chosen for the Sprint that has little or nothing to do with the Product Goal.