A colleague, Tom, told me about this question he received in an interview:
“The product owner and dev team cannot decide on a sprint goal, even after hours of discussion. They (the team) feel that the tasks for the sprint are too varied to manage to a single sprint goal. What should the Scrum Master do?”
Here are all the assumptions in this question:
- We need sprint goals. (Yes, I know the Scrum Guide says each sprint deserves a sprint goal. More below.)
- It's totally fine to spend hours trying to decide on a sprint goal. (Hours!!)
- The product owner is not part of the team.
- Too many varied tasks might mean the product owner treats the team as if it's a feature factory.
- That the Scrum Master has a specific action after hours of discussion. (Hours!!! Yes, I know I said that above, but please. Hours!)
I'm going to debunk all these assumptions in turn. Let me start with the idea of a sprint goal.
Sprint Goals Clarify a Specific Piece of a Product Goal
I don't happen to find sprint goals that useful, but some teams do. And since the Scrum Guide now demands a sprint goal, I guess you need a sprint goal to say you're doing Scrum. (I would just not say we're doing Scrum, but that's me.)
However, here's how I've used sprint goals: As a way to clarify what we want for the product goal in this sprint.
Let's imagine we have a product goal for the next release of our whiz-bang product. (I wrote a lot about how to create your project vision in Manage It! and Create Your Successful Agile Project.) That product goal is an overarching goal that answers the questions of which customers and the value they will receive from this release.
Some sprint goals are relatively easy to describe. Here's an example of one product's sprint goals:
- Sprint 1: Release the most common payment type for our customers.
- Sprint 2: Experiment with a UI change to see how it affects data speed. Internal release only.
- Sprint 3: Release the tax report by state.
- Sprint 4: Release the next four most common payment types.
- Sprint 5: Release the tax report by country.
After Sprint 5, we still have one more payment type. In Sprint 5, we learn that a specific country will change its taxes in the next quarter. So we can't change the taxes until then.
The team has iterated through all the feature sets and now has some random finishing: the last payment type, the tax change, and a couple more random stories we have not completed. Product goals help us decide.
Product Goals to the Rescue
What do we do for the sprint goal? There is no real sprint goal. We could:
- Ignore the idea of a sprint goal.
- Use this as the sprint goal: Finish the project now.
- Discuss the fact that we don't want to be a feature factory.
Instead, consider the product goal or what I call the product vision. (See What's Your Project Vision?)
Product goals specify the customers and what they will get from the release.
If you can't agree on a sprint goal, why not optimize up for the product goal? The more we optimize up for goals, the more likely we have a meaningful goal. The more we optimize down, the less meaningful the goal is.
A meaningful goal might prevent feature factory thinking.
Feature Factories Don't Contribute to Overarching Goals
The image on the left is from a real team that the product owner treated as a feature factory. Each of the colored boxes refers to a different feature set. The red boxes are defects the team needs to fix.
There's plenty wrong with this picture, including the fact that Sprint 4 here has more work than the other three sprints. Assume the boxes in this figure are index cards, and bear no relation to the size or complexity of the work.
There is no clear goal in any of the sprints. Worse, there was no clear product goal, because this team was cleaning up after other teams.
This product owner has feature-itis, big time. However, I suspect that given that the team's role was to clean up, I wonder if the team could have a product goal or a sprint goal.
Don't blame this product owner for randomness. A big part of the problem was management declaring the previous products were done before the products were actually done.
I am sure I'm not the only person who's seen this problem in agile teams, especially when they use Scrum. When teams have product and sprint goals, the product owner and the team can avoid the problem of being a feature factory.
That's why I like to start with product goals.
Start with Product Goals, Derive Sprint Goals
When a team starts with a product goal, they are more likely to succeed in a given sprint, because they know where they need to go. They—along with the product owner—can choose when to prototype as part of a sprint goal and what to deliver when.
When we optimize up for a product goal, we reduce premature optimization.
But that's just one of the problems in this interview question above. In the next post, I'll discuss how long a team might spend planning anything.
The Series:
- How Product Goals Make it Easier to Create Sprint Goals and Reduce Feature Factories, Part 1
- How to Reduce Planning Time to Create Better Goals at All Levels, Part 2
- Integrate Product Owners into Many Teams to Create Good Product Goals, Part 3
- How Scrum Masters Use Facilitative Leadership Especially When Planning, Part 4
- How Interview Questions Reveal the True Organizational Assumptions & Culture, Part 5