Many teams grapple with the intricacies of Scrum, and one of the most pivotal components is the Sprint Goal. It’s not just a fleeting thought or a mere list of tasks; it’s a commitment, a promise, and a clear direction.
Thanks to our reviewers: Ralph Jocham | Scrum.org
The Sprint Goal is the heart of Scrum, representing the team’s commitment to the value derived from the Sprint’s outcome. It’s the tactical step towards the objectives of the work in progress towards the Product Goal. A well-crafted Sprint Goal is neither granular nor high-level but strikes a balance to ensure clarity, accountability, and value delivery.
The Core of the Sprint Goal
The Sprint Goal is the commitment made by the Scrum Team to the value derived from the Sprint’s outcome. It’s the next tactical step towards the objectives of the work underway. This goal should be a clear and concise description of the work the team will undertake during the Sprint so that they can collectively manage the emergent Sprint Backlog. It’s not a list of tasks but a unified goal the team strives towards.
When teams find it challenging to craft a Sprint Goal that genuinely represents the contents of the Sprint Backlog, they might be aiming for too much granularity (a local optimisation). The Sprint Goal should be the paramount deliverable for which stakeholders will hold the Scrum Team accountable.
Conversely, a Sprint Goal that’s too high-level can disconnect the work being done from the value being delivered. This can create a chasm between the team and the outcome, diluting accountability.
Sprint Goal videos!
Some folks prefer to watch than to read :), and we have you covered:
This video sheds light on the concept of a Sprint goal in the Scrum context. It emphasises the Sprint goal’s tactical nature, which bridges the strategic vision and the intermediate strategic product goal. The Sprint goal should be something stakeholders can review and provide feedback on.
Here, the process of crafting a Sprint goal is unravelled. Teams can amalgamate information on the product’s strategic direction, the product owner’s current tactical direction, and ongoing engineering aspects. This synthesis helps in selecting the right items from the product backlog for the Sprint.
Addressing the often-asked question of how a Scrum team decides on a Sprint goal, this video highlights the collaborative effort required. It’s not a spontaneous decision involving developers, the product owner, and stakeholders. The goal should resonate with stakeholder feedback, market insights, and the broader business context.
Diving deeper, this video explores the markers of an effective Sprint goal. A well-defined Sprint goal sparks intrigue, questions, and enthusiasm among both stakeholders and developers.
Key things to remember about a Sprint Goal
The Sprint Goal connects the team and the stakeholders – we commit to the Sprint Goal as a team, and we expect the stakeholders to hold us accountable for achieving it. With the Sprint Goal being achieved as the norm, we build trust for the times when we occasionally don’t make the Sprint Goal.
The Sprint Goal does not need to represent all of the work in the Sprint – You will also have to plan time in each Sprint for refactoring, refinement, those small changes that are too short for a Sprint, and those ling running pieces of work that take longer.
Delivering usable product to at least some subset of real users every iteration (including the first) and gathering feedback? – While we strive to have usable value at the end of every Sprint, different sorts of work have different delivery models, and not all delivery can be sliced in the same way as software. For example, a tunnel is not valuable until both ends are open. This needs to be taken into consideration when crafting Goals.
When are Sprint Goals crafted?
While the Sprint Goal is finalised at the Sprint Planning, it is a good idea to think longer term and draft possible Sprint Goals looking out at least the next few Sprints.
While they may change, having some idea of which checkpoints you are thinking of hitting is critical to helping both the team and the stakeholders make better decisions with as much context as makes sense. If you find that you are changing the draft Sprint Goals constantly, then maybe you are looking too far out into the future and need to shorten the forecast.
This forecast should be sufficient to enhance transparency and will depend on the type of work underway.
Examples of Sprint Goals
Here are some examples of Sprint’s Goals for a cloud migration team migrating applications from on-premises to the cloud. These goals may be delivered in this order over the life of the engagement or partnership with a customer and represent vertical slices of work to be delivered that result in some value.
SMART Sprint Goals
These are just example goals, and the specifics will vary based on the organization’s needs, the complexity of the applications, and other factors. One way to ensure the validity of each sprint goal is to use SMART goals; each goal is specific, measurable, achievable, relevant, and time-bound.
Environment Setup Sprint Goal – “By the end of this sprint, we will have a fully configured cloud environment, including virtual networks, security groups, and storage, ready for application deployment.”
Assessment and Planning Sprint Goal – “By the end of this sprint, we will have identified all dependencies, potential challenges, and the migration strategy for each application.”
Proof of Concept (PoC) Sprint Goal – “By the end of this sprint, we will have successfully migrated a non-critical application to the cloud and validated its functionality, serving as a PoC for the larger migration.”
Data Migration Sprint Goal – “By the end of this sprint, we will have migrated 50% of the application data to the cloud without any data loss or corruption.”
Application Migration Sprint Goal – “By the end of this sprint, we will have migrated and deployed three key applications to the cloud and ensured they are fully operational.”
Integration Testing Sprint Goal – “By the end of this sprint, we will have completed integration testing for all migrated applications, ensuring they interact seamlessly with other systems.”
Performance Tuning Sprint Goal – “By the end of this sprint, we will have optimized the performance of all migrated applications, ensuring they meet or exceed on-premises benchmarks.”
Security and Compliance Sprint Goal – “By the end of this sprint, all migrated applications will be compliant with our security standards, and any vulnerabilities identified will be addressed.”
User Training and Documentation Sprint Goal – “By the end of this sprint, we will have provided training to all relevant stakeholders on how to use the migrated applications in the cloud environment and created comprehensive documentation.”
Monitoring and Alerting Sprint Goal – “By the end of this sprint, we will have set up monitoring and alerting tools for all migrated applications, ensuring we are immediately notified of any issues.”
Final Transition and Decommissioning Sprint Goal – “By the end of this sprint, all remaining applications will be fully migrated to the cloud, and on-premises infrastructure will be decommissioned.”
OKR Sprint Goals
This same list can be written as OKR! OKRs (Objectives and Key Results) are a goal-setting framework that helps organizations define and track objectives and their outcomes. Here’s how the list of Sprint Goals can be converted to OKRs:
Objective: Successfully migrate applications from on-premises to the cloud.
Environment Setup – KR1: Fully configure the cloud environment, including virtual networks, security groups, and storage.
Assessment and Planning – KR2: Identify all dependencies, potential challenges, and migration strategies for each application.
Proof of Concept (PoC) – KR3: Migrate and validate a non-critical application to the cloud as a PoC.
Data Migration – KR4: Migrate 50% of the application data to the cloud without data loss or corruption.
Application Migration – KR5: Migrate and deploy three key applications to the cloud, ensuring full operability.
Integration Testing – KR6: Complete integration testing for all migrated applications with successful interactions.
Performance Tuning – KR7: Optimize the performance of all migrated applications to meet or exceed on-premises benchmarks.
Security and Compliance – KR8: Ensure all migrated applications comply with security standards and address any vulnerabilities.
User Training and Documentation – KR9: Provide training to all relevant stakeholders and create comprehensive documentation.
Monitoring and Alerting – KR10: Set up monitoring and alerting tools for all migrated applications with immediate notification capabilities.
Final Transition and Decommissioning – KR12: Fully migrate all remaining applications to the cloud and decommission on-premises infrastructure.
The Objective sets the overarching goal, while the Key Results break down the specific, measurable outcomes that indicate progress towards achieving that goal.
Other Goal-definition frameworks
In addition to the SMART and OKR goals listed above there are other frameworks that are also viable in this circumstance:
Collaborative: Goals should encourage teamwork.
Limited: Goals should be limited in scope and duration.
Emotional: Goals should connect to personal and team values or passions.
Appreciable: Break larger goals into smaller tasks.
Refinable: Be flexible and adjust goals as needed.
BHAG (Big Hairy Audacious Goal):
A long-term, visionary goal that is more strategic and inspiring than a standard goal.
4DX (The 4 Disciplines of Execution):
Focus on the Wildly Important Goals (WIGs).
Act on Lead Measures.
Keep a Compelling Scoreboard.
Create a Cadence of Accountability.
Ambitious in scope.
Specific and measurable.
Transparent and shared with others.
Used primarily for coaching and mentoring.
Goal: What do you want to achieve?
Reality: Where are you now concerning the goal?
Options: What could you do to achieve the goal?
Will (or Way Forward): What will you do?
MBO (Management by Objectives) – A management model where managers and employees work together to set, monitor, and achieve specific objectives.
Backward Goal Setting – Start with the end goal and work backwards to determine the steps needed to achieve it.
Process vs. Outcome Goals:
Process Goals: Focus on the actions or strategies needed to reach a goal.
Outcome Goals: Focus on the desired end result.
Different frameworks and methodologies may be more suitable depending on the context, the nature of the goal, the individual or organization’s preferences, and the desired outcome. Choosing a method that aligns with the specific needs and challenges at hand is essential.
Mastering the art of crafting a Sprint Goal is pivotal in the Scrum framework. It’s not merely about listing tasks but about setting a clear, concise objective that drives value and aligns with the broader vision. Whether too granular or too high-level, a misaligned Sprint Goal can hinder a team’s progress and diminish stakeholder trust. By understanding its essence and ensuring it’s tactical and relevant, teams can foster better collaboration, clearer communication, and heightened accountability. Remember, it’s not just about completing tasks; it’s about delivering value, every Sprint.
NKDAgility can help!
If you find it hard to craft effective Sprint Goals or struggle to align your team’s objectives with the broader organisational vision, my team at NKDAgility can assist. Lean-agile practitioners thrive on these kinds of challenges, but most teams find daunting.
Don’t let these issues undermine the effectiveness of your value delivery. It’s paramount to seek assistance sooner rather than later!