Sprint goals are one of the most widely misunderstood artifacts of Scrum. They are often misused at first. We misused them and went through several stages as we improved how they were created.
Every 2-3 months, we'd establish a set of release goals, often in the form of "epic stories", that established a vision for the release. Doing this led us through three stages of how we created sprint goals:
Stage 1 - break the epic goals down into many development tasks to fill up our product backlog before handing it to the team. This required a lot of "producer-like behavior from the Scrum Masters managing the product and sprint goals.
Stage 2 - Have the teams become more involved in that breakdown. Release plans still had a lot of PBIs that looked like requirements derived from design decisions that were locked in at the start of the release. Sprint goals were still mainly a collection of requirements, but with a better definition of done.
Stage 3 - A shift to having a discussion at the start of each sprint about how we could move one or more of the epic stories forward in the sprint. Design decisions were spread out more evenly throughout the release. Sprint goals were usually a sentence about what the team forecasted could be played in the improved game at the end if the sprint.
An example of how this looks with an epic story:
"As a player, I want to engage in hand-to-hand combat with an enemy player"
Stage 1 - Write a document that described the hand-to-hand combat and break out a designed development order into a large set of sprint-sized PBIs with estimates for each. There wouldn't be much to see until the end of the release. Backlog refinement didn't happen because there was little to see in early sprints, so there was little to reflect against the release plan. Releases always ended with crunch.
Stage 2 - Work out a release plan with the team. There was still a a lot of task-like PBIs split out and design decisions were front loaded. But teams had more to show each sprint and started to hold backlog refinement sessions throughout the release. The end of the release was still a scramble to have hand-to-hand combat shippable.
Stage 3 - Don't create a release plan, but discuss with the team how we could move the hand-to-hand combat forward each sprint. Backlog refinement and sprint planning merged.
Stage 3 scared the devil out of management. It required a bit of trust established by a highly functioning team delivering high quality work at a consistent pace. Also, it was first attempted when we were given three months to do something very risky that should have taken six months, but it demonstrated the following benefits:
- It focused the team on the player essentials. Sprint one implemented the controls and cameras of combat and not the polished animations. You can have fun and learn a lot with simple blends and placeholder reactions.
- It reduced risk and cost by exploring the essentials first and postponing design decisions as long as we could responsibly postpone them. Very often design decisions made far in advance are more complex than what is needed and lead to waste. In this case, a high/medium/low hit detection approach was the simplest solution that worked well enough initially, but had the benefit of being tweaked over the remainder of the release.
- It delivered early. We could have shipped it in two months, but took the extra two sprints to add elements beyond the release goal.
This wasn't isn't about doing things "right" or "wrong". We're always inspecting and adapting how we make games and must always assume there are things we can improve. As long as teams are doing that, they're on the right path.