The Sprint Goal


Everybody needs to have goals these days…. Whether you want to or not! It could be as part of an appraisal process or a team at work… Often these are medium to long term aspirations which nobody ever checks the progress of!

However, For those that read my The Ten must do’s of Scrum one of the artefacts I list is the Sprint Goal This is one of those often overlooked aspects of doing Scrum but like time boxing it’s an excellent way to keep things targeted.


Who sets the sprint goal?

Ideally the goal of the iteration should be set by the product owner ( PO), It’s their opportunity to set the agenda and to ensure that everyone understands what the focus of the sprint is. It’s also the responsibility of the scrum team to commit to the goal or if the goal is unobtainable within a single iteration to explain this to the PO. In determining if a goal is achievable the final say is with the scrum team and the PO should be respectful of their opinion (That doesn’t mean that the PO shouldn’t challenge the team however)


Determine the stories that deliver the goal

One of the agile ‘games’ I like to play when facilitating a sprint planning session is to get the PO to come to the ceremony with the goal already thought out and written on an index card.

I then stick that card to the board and get the team to look at the user stories and pick only those that supports the goal of the sprint.

Whilst this is typically the domain of the PO – I like to mix things up from time to time and it’s good to get the scrum team involved and thinking about the product – However, The PO always has the final say and veto powers!

Once we’ve agreed what user stories support the goal we then prioritise the user stories… I like to keep this activity ‘real’ and ‘physical’ so I get the team to move the user stories around on the board – Sometimes I get the PO to set the sequence… But another nice ‘game’ is to split the user-stories up between the team members and get each person to pin the story where they think it belongs. Once the user-stories are sequenced we discuss and re-sequence as required but again the PO gets the final say.


So what makes a good Sprint Goal?

When I was in the murky world of management I was responsible for doing appraisals and discussing/setting an individual’s goals… These goals had to be S.M.A.R.T: Specific, Measurable, Attainable, Relevant and Time bound.

Well the time-bound part is easy – all sprints should be time boxed and the goal is relevant for the duration of the sprint.

In the early days of a project the goals might address uncertainty and investigating the domain – as time goes by the sprint goal should be targeted towards completing the most relevant features required to deliver the product vision.

Ensuring that your goals are specific and measurable is essential for determining success and should form part of your definition of done for the sprint.

Don’t create goals that are vague and just read “Create a prototype of the forecast report” instead try “Create a paper prototype to demonstrate the forecasting reports to the chief management accountant” This helps to ensure that the goal is relevant and measurable.
Scrum is all about rapid feedback. The delivery of the sprint should be demonstrated in the Sprint review to the relevant stakeholders and PO – Or better yet get the PO to demo to the stakeholders – Doing this helps to break down barriers and encourages a more collaborative approach.


In Summary

Having a sprint goal encourages focus and facilitates teamwork towards a single well understood goal, appraisal of the sprint is easier and stakeholder engagement and satisfaction should improve.

But probably the most important advantage of all… When the ‘big boss’ asks what you’re working on – you have a clear defined answer to respond with… rather than babbling on until their eyes glaze over and they walk off!

Popular posts from this blog

Why do agile IT 'projects' fail?

The 5 Core Values of Scrum