The Angelina Jolie Blog Post
“After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment”
– The Scrum Guide, Schwaber & Sutherland
Most Scrum teams, in my experience, take as much of the highest priority Product Backlog items they can commit to for the Sprint and then work on identifying the necessary tasks to get them “done” during the Sprint. This is not a bad thing, but it’s not the best thing. In my experience, teams with a Sprint goal experience less frustration, greater focus, greater synergy, fewer cancelled Sprints, and have more fun. I would go so far as to say that the most successful Scrum teams I have seen have Sprint goals.
“I think one of the most glossed-over parts of Scrum in teams is the concept of a Sprint goal. My main concern with this is not that people aren’t doing Scrum properly but that they are missing out on something that could give their teams, projects and products a massive boost.”
By committing to a Sprint goal rather than specific Product Backlog items, it gives the team (the whole Scrum team not just the development team) much greater flexibility in the evolution of the delivery during the Sprint. The focus moves away from sticking to the Sprint plan and towards delivery of the Sprint goal – doesn’t this sound more agile? The conversations seem to be a lot more collaborative in teams with Sprint goals than those who don’t use them
A good Sprint goal keeps the intent of the work in the forefront of the team. It helps them see how this Sprint is contributing towards the overall vision for the project. Teams with Sprint goals claim it is more motivating than having merely a list of Product Backlog items or User Stories. Focus is one of our Scrum values and encouraging creativity and exploration are other highly encouraged principles within a Scrum development team. A Sprint goal seems to feed into those quite nicely.
One issue that Mark Levison had when he posted his views about Sprint goals in 2010 was “If the [Product Owner]’s needs for a given sprint are a series of disparate user stories, I don’t see how we can create a real sprint goal”. My personal experience indicates that all of the best Product Owners I have seen work hard to ensure that the Sprint is not full of disparate user stories. They see the massive benefits of having related items together in a Sprint as, through the synergy of these items, this increases the ROI of the Sprint increment significantly, even if we are not picking all of the top priority items.
By encouraging people to think about the Sprint goal we are putting in place a mechanism for increasing ROI through synergy, not to mention the extra motivation provided to the development team by having a clear, concise goal.
Fewer Cancelled Sprints
Cancelled sprints, or “abnormally terminated Sprints” as they are otherwise known, are horrible. Nobody likes them. They are costly and wasteful, yet sometimes they are the right decision. Usually, however, we would like to avoid them wherever possible. Again, just from my own experience, I see less cancelled Sprints where the team have a Sprint goal than when they don’t.
As Mark points out, the Scrum Guide says:
“The reason for having a Sprint Goal is to give the Team some wiggle room regarding the functionality. For example, the goal for the above Sprint could also be: ‘Automate the client account modification functionality through a secure, recoverable transaction middleware capability.’ As the Team works, it keeps this goal in mind. In order to satisfy the goal, it implements the functionality and technology. If the work turns out to be harder than the Team had expected, then the Team collaborates with the Product Owner and only partially implement the functionality.”
I wholeheartedly agree with Mark on this point. If the team needs “wiggle room” the Sprint goal is not the way to achieve it. Collaboration and honest conversation with the Product Owner is the way to deal with that issue.
However, having this focus on the goal rather than the predicted details of the functionality does allow us to collaborate on how we solve the problem during the course of the Sprint. So if we find a way of solving a customer problem that is different to the way we identified at the start of the Sprint we can make that change without jeopardising the Sprint goal and thus needing to cancel the Sprint.
One note of caution here: developers may not jump at this at first as the anxiety of starting work without wireframes may be too high in their context.
Have more fun
Fun is a by-product of a truly agile approach in my experience. One other consistent pattern that I have seen is that teams with a Sprint goal seem to have more fun, and this is represented in the Sprint goals they have as well. For example, one team had the Cristiano Ronaldo sprint (in their theme of footballers as Sprint goals) because this Sprint was primarily focussed on making it look pretty. One team had a Wall Street Sprint (their theme of Sprint goals was movies) as it was focussing on risky money-making functionality. Another team had a Paris Hilton Sprint – I won’t say why they chose Paris!
Other examples of themes for Sprint goals:
- Children’s games
- Biscuits or snacks
- Nursery rhymes
How to form Sprint goals?
The Scrum Guide suggests a bottom-up approach to Sprint goals i.e. the team select the highest priority Product Backlog items and then try to construct a Sprint goal from them. Another option is the top-down approach i.e. create a Sprint goal and then select the highest priority Product Backlog items that fit that Sprint.
I ran an experiment last week. I took a Product Backlog and created six Sprint goals, allocating the Product Backlog items to those Sprint goals. I gave 2 groups the goals and asked them to allocate the Product Backlog items into six Sprints guided by the given goals i.e. the top-down approach
2 groups were asked to categorise and create Sprint goals from the same Product Backlog items i.e. the bottom-up approach.
The teams starting from the Sprint goals found this exercise much easier than the teams working in the bottom-up approach. I think this might be a reason why teams often skip the Sprint goal. I’m not suggesting teams should take the top-down approach as this could ignore the ordering of the Product Backlog but perhaps a mixture of the two might be a good idea.
So why have I named this the Angeline Jolie blog post? Post your ideas in the comments section: