Sprint Goal
- Sprint Goal (Purpose) – Commitment of the SB – measurable - desired outcome – why
- why the Sprint is valuable to stakeholders
- The Sprint Goal is an objective set by the Scrum Team during Sprint Planning and captures:
- the hypothesis that the team wants to test
- a goal it wants to achieve
- an experiment to run
- is an objective for the Sprint that will be met through implementing selected work from the Product Backlog
- It “offers guidance to the Development Team on why it is building the Increment
- Sprint Goal is FIXED during the Sprint: it is SET IN STONE
- “The selected PBIs deliver one coherent function, which can be the SG. But the SG can be any other COHERENCE that causes the Development Team to work together rather than on separate initiatives”
- Most of the reasons why Scrum Teams and organizations struggle with Scrum can be traced back to missing Sprint Goals and — behind that — not understanding the reasons for working with Scrum
- Sprint Goals are intended to help organizations break free from this output-driven approach, where the focus lies on efficiency and getting as much work done as possible, by focusing on valuable outcomes and an experimental mindset
- Spring goal can mitigate a very significant risk which ultimately makes a Sprint Backlog more than the sum of its parts
Myth: Having A Sprint Goal Is Optional In Scrum
- Characteristics
- Advantages:
- Provides Guidance
- helps to focus
- promote collaboration: encouraging to work together
- the single objective for the Sprint
- is a commitment by the Developers
- provides flexibility in terms of the exact work needed to achieve it
- Without Sprint Goals:
- the whole framework unravels
- Scrum Events lose their purpose
- Scrum Teams have little reason to collaborate
- organizations don’t start to think in terms of value
- When no Sprint Goal…
- … a wide variety of items will be pulled
- … the Sprint Backlog is likely what implicitly (or explicitly) commits to
- … no obvious incentive to collaborate
- … the Daily Scrum takes the form of a status update
- … members will complete ‘all their work’ at different moments of the Sprint
- … it is hard to know who to invite to the Sprint Review
- … the Development Team doesn’t have guidance on how to decide
- … it is hard to know when a Sprint is successful
- … complain that Scrum Events take a lot of time and feel ineffective
- … This makes all Sprints the same
- Reasons for not having a Sprint Goal
- … Product Owners don’t have the mandate on the PBI and what order
- … Product Owners don’t have a vision or strategy for the product
- … Product Backlogs span thousands of items
- … Scrum Teams may be too large
- … Scrum Teams may work on different products or projects at the same time
- … Sprints may be too short or too long
- … Scrum Teams may be organized as ‘component teams’
- … reverse-engineer a Sprint Goal
- … Some teams do work that is not suited to the time-boxed and purpose-driven nature of Sprints
- Tips
- … Help Product Owners plan ahead by identifying potential objectives for upcoming Sprints
- … use the Liberating Structure Nine Whys
- … ask powerful questions to help Product Owners dig deeper into the “Why” of their decisions
- … The Sprint Review offers potential objectives for the next Sprint(s) Liberating Structure like What, So What, Now What
- … Use a template to craft Sprint Goals
- … Make your Sprint Goal transparent
- … Begin each Scrum Event by stating the Sprint Goal
- … Don’t worry if you can’t relate all the items on a Sprint Backlog directly to the Sprint Goal
- … find Sprint Goals that offer guidance during the Sprint and promote collaboration in your team
- Challenges with the Sprint Goal
- There is no Sprint Goal
- The work is the Sprint Goal
- There is no room for anything else
- There is no focus on the Sprint Goal
- The goal is not a goal
- Challenges with the Sprint Goal
- The Sprint Goal is too big
- The Sprint Goal is vague
- The team doesn't pay attention to the Sprint Goal during the Sprint
- The Sprint Goal doesn't feel meaningful
- Six Reasons Why You Need to Pay More Attention to the Sprint Goal. The Sprint Goal…
- … gives the Development Team some flexibility
- … gives sense to the tasks and motivates the Team
- … unites the Development Team
- … helps in managing risks
- … helps with focus and making decisions
- … helps manage stakeholders' expectations
- Models
- This Sprint exists to… (outcome)
The 11 Advantages of Using a Sprint Goal
- What is a Sprint Goal?
- is an objective set for the Sprint that can be met through the implementation of PB
- is a result of a negotiation between the PO and the DT
- Sprint Goals should be specific and measurable: do not mean SMART
- the selected work for the SB is a forecast, the DT gives their commitment to achieving the SG
- 3 types
- addressing a risk
- testing an assumption
- delivering a feature
- Why using a Sprint Goal?
- Serves to test assumptions, address risks, or deliver features
- Ensures a focused Daily Scrum, because the DT can use it to inspect their progress against to
- Provides guidance to the Development Team on why it is building the Increment
- Offers flexibility regarding the functionality implemented within the Sprint
- Helps setting priorities when "the going gets tough"
- Fosters teamwork and teambuilding by jointly working towards a shared Sprint Goal
- Supports the Product Owner in creating the product roadmap
- Stimulates Product Backlog cohesion when planning a release
- Can be used as an instrument for stakeholder management
- Supports a focused Sprint Planning by crafting a shared Sprint Goal
- Enables efficient decision-making
- Template Overview
- How to Choose a Sprint Goal?
- offers three questions to consider
- GOAL - OUTCOME: Why do we carry out the Sprint? Why is it worth? What should be achieved?
- METHOD - OUTPUTS: How do we reach its goal? Which artifact, validation technique, and test group are used?
- METRICS - MEASUREMENTS: How do we know the goal has been met? For instance at least three of the five users carry out the usability test successfully in less than a minute
- additionally, a header section to state to which product and sprint
- many POs and teams don’t leverage sprint goals or don’t apply them correctly: Sprint goals often state the stories to be implemented rather than the reason for undertaking the iteration
- GOAL - OUTCOME:
- why it is worthwhile to undertake the sprint
- Examples are:
- Test an assumption about the user interaction and learn what works best for the user: “Will users be willing to register before using the features?”
- Address technical risk: “Does the architecture enable the desired performance?”
- Release a feature:: “Get the reporting feature for general release.”
- The sprint goal should be shared: The PO and the DT should believe that working towards the goal is the right thing to do
- To choose the right sprint goal I find it helpful to consider the uncertainty present. In the early sprints, addressing risks and testing assumptions. Once the key risks and critical assumptions have been dealt with, I like to focus on completing and optimizing features
- METHOD - OUTPUTS:
- how the goal is met
- Create a (potentially shippable) product increment using the high-priority PBIs
- But creating software and a demo are not always the best to achieve the goal!
- A paper prototype can be good enough to test a visual design idea or an assumption about the user interaction, for instance.
- What’s more, other methods such as carrying out a usability test or releasing software to run an A/B test may well be more effective than a product demo
- You should therefore carefully choose the right method and state it in this section
- But don’t stop there. Determine the test group, the people who should provide feedback and data. Who these individuals are depends on the sprint goal:
- METRICS - MEASUREMENTS:
- The Header Section
- Sprint Goal, User Stories, and Sprint Backlog