As a part of Agreement-Based Planning, the Team should decide on a Sprint Goal, which will define the ultimate success or failure of the Sprint. The main purpose of the Sprint Goal is to provide a focus on something besides finishing all the Stories and provide wiggle room for the Team to work within. This is important for many Teams because, without it, the Team’s de facto goal is to finish all the Stories they agreed to – and this pressure to finish all of them often leads to the unintentional creation of Technical Debt (see chapter 3.5). Having something else to focus on that defines success allows the Team to do the work necessary to get the Stories done right.
The Sprint Goal should be determined by the Team at the end of Sprint Planning, even though it may be discussed with the Stakeholders at the Review. I like doing it at end so that there isn’t a long, protracted discussion about it. Since Sprint Planning is time-boxed, holding it at the end limits the amount of wrangling the Team can go through about it.
The Sprint Goal defines success, and can be about Product, Process, or People. Most people think the Sprint Goal should be a subset of the Release Goal, or a milestone along the way, or something like that. I think that is too narrow a view. I think that the Sprint Goal is what is actually important in this Sprint, and this is not always about the Product. Let’s just see some examples of Sprint Goals.
- ‘Have something to Review’-the default Scrum Goal for any Sprint.
- ‘Have a releasable version of <Buy an e-Ticket>’ – indicating that, even though the Team is almost there, and everybody thinks it shouldn’t take much more effort, make sure you get ‘Buy an e-Ticket’ ready to go – even if it means reprioritizing the other Stories in the Sprint or creating Technical Debt.
- ‘Clean up Module ABC’ – indicating that, even though functional Coding Stories have been agreed to, and are important, what is really important is cleaning up some Technical Debt.
- ‘Release the Product’ – indicating that it is imperative that the Product go out the door. Do whatever it takes, including sacrificing features, quality, and work/life balance – but get it out the door.
- ‘Bring the new people, Joe and Gina, up to speed’ – indicating that speed of development may be sacrificed if it helps in knowledge-sharing with the new Team Members.
- ‘Be able to write ‘real’ code the first day of the next Sprint’ – this is common for a so-called Sprint Zero (see chapter 4.9) and indicates that the Team needs to do enough analysis, have enough development environment, have enough training, and so on, so that it can begin production immediately. This is used to eliminate a long, up-front, setup period.
- ‘No Technical Debt in this Sprint’ – let’s actually follow the rules and take no shortcuts this time, shall we?
- ‘Everybody goes home by 6:00pm’ – we need to get our work/life balance back, and stop working at an unsustainable pace.
- ‘Nobody works alone this Sprint’ – everybody pairs or swarms, let’s just bite the bullet and get used to it…
- ‘Keep Improving <Buy an e-Ticket>’ – which indicates that the Team should just keep doing what it’s doing, but focus on the ‘Buy an e-Ticket’ capability…
Once the Sprint Goal is determined it should be announced to the Stakeholders, and it should be adhered to as a focus throughout the Sprint. Remember that this is what defines success for the Sprint, and must be the primary focus. It is the ScrumMaster’s job to make sure the Team keeps focused on this Goal throughout the Sprint.
This concept is discussed in greater detail in chapter 4.2 of Exploring Scrum: The Fundamentals which you can purchase on Amazon.