Skip to content

The Sprint Goal - Daedalus Coaching

Sprint Goals

Sprint Goals are Focusing Tools

  • With a good goal, you'll all be working in a related area, which makes Stand-ups more interesting, PRs need less context-switching, and you get more done in the most important area - and the most important feature thus goes live sooner

    • The PO is responsible for maximising the ROI from the team - by setting the best direction, given what we know about customer needs. That doesn’t mean they have to do all the work breakdown alone.

    • The team knows best how much can be done in a fortnight, but also has a lot to offer the work breakdown and refinement process

    • The art is to practice working as a team on these areas until this joint effort really does offer a better return on your time invested than separating the work breakdown from the doing of sprint items by role.

Effective Sprint Goals

Effective Sprint Goals

An effective Sprint Goal:

  • Can be realistically achieved within the timeframe of a Sprint

  • Focuses on delivering customer or business value, not just completing tasks: the outcome, not just the output

  • Energises the team, providing a sense of purpose and direction - you can get excited about the impact of your work

  • Gives a simple, shared understanding of why it's important

  • Aligns with the Product Goal, the broader objectives of the product

  • Allows for some flexibility to adapt to unforeseen changes without losing sight of the main objective

Common Errors and Anti-Patterns

Common errors include:

  • Not agreeing on a Sprint Goal - this makes it so much harder to work as a team on a common purpose

  • “Getting the PBIs to Done” is not a Sprint Goal, it’s “the work you do to meet the Sprint Goal"

  • Overly ambitious goals, impossible to achieve within the Sprint, are demoralizing rather than motivating

  • Focussing solely on technical achievements or task completion, rather than customer or business value

  • Deviating from the overarching product goals fragments efforts and a lack of coherent progress.

  • Making the goal too rigid, such that it introduces inefficiencies or missed opportunities, especially when unforeseen challenges arise.

How to Declare an Effective Sprint Goal

The secret is to agree on the Sprint Goal in Sprint Planning, part 1, and only then agree on the most valuable PBIs (in Sprint Planning part 2), Then, devise a plan for how you'll do the work (Sprint Planning, part 3).

  • Many teams only do part 2, so you may need to allow more time for Planning - BUT you should see a better return on your time invested, e.g. better forecasts, smoother delivery, more sprint goals met; happier stakeholders, and happier team

  • Part 3 is where you deal with the complications of dependencies etc. Either your plan accommodates them OR you rework the Sprint Backlog (possibly removing/replacing PBIs)

You only declare the Sprint Backlog when you leave Sprint Planning (after parts 1, 2, 3) - it comprises: the Sprint Goal; the Forecast (PBI 'commitment'), and; the Plan for success)

  • Don't leave the Planning session until you (all) genuinely feel the forecast is realistic - specifically, that: you have high confidence that you can together deliver the Sprint Goal within 2 weeks

  • This needs everyone’s input. Actively seek opinions, ensure everyone has had the opportunity to share their perspectives; welcome questions, and use them to better understand the work, and crucially, be mindful of your role in establishing and maintaining psychological safety for your teammates.

The Timebox

  • If you can regularly and successfully achieve this within the timebox, (such that the Sprint Goal is subsequently met), you are doing well.

  • If you cannot yet plan your Sprint, within the timebox, such that it is delivered successfully most of the time, however... there is enormous opportunity (value) here: focus your Retrospectives on: identifying these opportunities; forming and testing hypotheses to improve the situation.

Proper Preparation

Sprint Planning is effective when you've done the (right) preparation - specifically:

Agree on a clear, larger Product Goal

This allows you to focus your refinement before you even arrive in Planning

You’ve agreed to DEprioritise PBIs unrelated to the Product Goal in refinement

Refine the most likely PBIs (aligned to that Product Goal) shortly before Planning

  • A Definition of Ready (optional) can help with consistency

Things go stale - what was refined 2 months ago may be incorrect now, and will certainly not be fresh in your minds

Refine the work in a way that suits HOW you’ll work it through it

Rather than simply WHAT needs doing. This is another difficult challenge.

  • Story mapping, etc. can be a huge helper here

Break stories down "enough - but not too much"

You're looking to achieve high confidence that you can meet your Sprint Goal within the Sprint. This is more likely with:

  • Smaller stories that you can confidently take from "Definition of Ready" to "Definition of Done" inside the Sprint

For a 2-week Sprint, look for stories that take 3-4 days to reach DoD (rather than 8-9 days) so you can confidently confirm progress by the middle of the first week (and spread testing effort more widely)

“Three Amigos”

When you pick up a new story, have a 3-party chat with a Developer, Tester and Product person, to confirm you have a shared understanding, and refine the plan for the story - based on what you know right now - the "latest responsible moment"

Refer to the Sprint Goal, during the Sprint, to drive decisions:

  • Which item to start next?

  • How do we best deal with this surprise learning?

  • Do we need to drop/swap/add an item to better meet the Sprint Goal?

  • Are we working on the most important work?

  • When should we do this BAU item?

Summary

For me, this captures the power of Sprint Goals for improving your experience of delivering customer value.

As you can see, it DOES mean changing lots of related elements of how you work - again, this itself is the power of using Sprint Goals.

To be explicit: the changes required to make good Sprint Goals achievable IS the benefit of using them

In Closing

The work is difficult - and it doesn’t get easier - simply, with practice and experience, YOU get better at it.