Why Sprint Goals are often a bad idea in Scrum
Xavier Quesada-Allué
Partner at Agilar, Certified Scrum Trainer, Enterprise Agile Coach, Co-creator of Vima
Sprint goals were introduced in Scrum with the release of the Scrum Guide in 2011. They were created to help teams focus on a clear objective for each sprint, enhancing alignment, collaboration and focus and allowing the Developers to have higher ownership of the work and increase chances of Sprint success as they provide "wiggle room" within the Sprint.
I remember vividly doing Scrum the days before the Sprint Goal existed. The way we would do it back then, the implicit "goal" of each Sprint would be to deliver everything the Development Team thought was possible to do within the Sprint. We would say "the Dev Team commits to delivering all this within the Sprint".
Today, I recommend Sprint Goals when the team is exclusively dedicated to new product development. They encourage treating each sprint as a "mini-project" focused only one feature or epic. In that context, I think they are -usually- a good idea.
But Sprint Goals are generally not recommended when:
- the product is already in production and new priority PBIs are small and spread across multiple epics / features / product areas
- the product is in maintenance mode
领英推荐
- the Team works on multiple products
- the Team has a high percentage of unplanned work coming in
- the Scrum Master observes low maturity among the Developers and Product Owner who regularly come up with invalid Sprint Goals such as "deliver PBI 1, 2 and 3" or "deliver all that is forecast".
- The Product Owner simply believes that the best strategy for the next sprint is to deliver many PBIs across multiple product areas, even if that would have an impact on focus or productivity of the team. They might have good reasons for their priorities.
Unfortunately I see all too many teams in these last scenarios. In 20 years of Scrum coaching, I can only count with one hand the number of product development teams that I've worked with that have been in a pure "early product development" stage where this practice makes the most sense. And I think forcing Spring Goals on a team that is not in this ideal scenario can do more harm than good, making the Scrum Master look like a dogmatist.
So, in the majority of cases, I'm still happy to live in a pre-2011 Scrum version and focus my Sprint Planning efforts on having a realistic forecast of high quality, well refined PBIs that deliver strong business value.
CTO of Alola, Creator of AMMERSE, Author, Software Developer, prebonsai startup
2 个月https://ammerse.substack.com/p/practical-ammerse-series-replacement
Ich arbeite als Advanced Certified Scrum Master und Product Owner mit praktischen Erfahrungen als Coach in agilen Transformationen.
8 个月I imagine that a sprint goal is just a metaphor for value creation and also for motivation. That is why it is hard to set. Anyway it’s a good idea to have a focus that doesn't just target a specific date, but also gives a sense of purpose. It certainly creates priorities and space for experiments and creativity. There is no compulsion to work only on things that contribute to the goal. Wait, do I still work at a sustainable pace? It is hard to imagine a goal in many environments. But I know it leaves a pretty good taste of achieving your goal. You can't achieve it either. Let’s inspect and adapt.
Product @ GlassesUSA | Founder @ Agile Potential
8 个月Reading your conditions: - the product is already in production and new priority PBIs are small and spread across multiple epics / features / product areas - the product is in maintenance mode - the Team works on multiple products - the Team has a high percentage of unplanned work coming in The question becomes - why use Scrum at all in these contexts? The issue doesn't seem to be sprint goals, but rather: 1. Why is the team working on multiple small PBIs with no focus on any product area? 2. Why are we using Scrum in maintenance mode? Do we even solve any complex product problems? 3. Why is 1 team working on multiple products? Is it really suitable for Scrum? Is it really suitable for one team? Is this the same as maintenance? 4. What's the cause of the unplanned work? Is Scrum a suitable framework to handle this case at all?
Re-designing work for collaborative learning
8 个月A substantial percentage of teams, especially in large organisations cannot have sprint goals because of the context they are in. They have too many priorities, too fragmented skills, too much interruptions, ... (see also Maarten Dalmijn ??'s posts on this topic). Likewise a large percentage of teams cannot have WIP limits. They have too many external dependencies, too little collaboration, ... Under the guidance of agile coaches they accommodate. The result is something that resembles the intersection between Scrum and Kanban, mostly with Scrum terminology. What is missed is that the value is not in the intersection but in the difference.