In an ideal world a truly cross-functional team members would be working on related stories and Sprint Goal makes good sense. However, in my experience (real life) team members will often have specialist skills (even with the best effort to up-skill and cross-skill) and teams will often be working on not-so-related stories e.g.
- Running workshop with customer for upcoming feature (driven by Business Analyst with involvement from the rest of the team)
- System architecture design spike for upcoming feature (driven by external or team Architect with involvement from the team).
- Important tech debt story (requiring deep Database skills).
- Current feature story.
- Maintenance story from existing product.
- High priority support ticket for old product still supported by the team.
Setting one good Sprint Goal for this Sprint Backlog is not trivial even with a clear prioritisation. Selecting one specific goal could be demotivating for the team members not working on something related to the goal and not capture what the team is trying to achieve in the Sprint.
Making the goal too fluffy to cover more stories doesn’t make much sense to me as it leaves more up to interpretation.
Having 6 Sprint goals is clearly not an option either (if everything is important then nothing is – P Lencioni).
I usually try with getting the team to agree 2-3 goals for the Sprint, but I must say that the engagement from the team is usually low to moderate.
I've tried implementing Sprint Goals with my teams, but hasn't worked yet.
Rather than trying to push for the Scrum by the book, we do what works best for us and we get results that we and the clients want. Isn't this the main goal?
In an ideal world a truly cross-functional team members would be working on related stories and Sprint Goal makes good sense. However, in my experience (real life) team members will often have specialist skills (even with the best effort to up-skill and cross-skill) and teams will often be working on not-so-related stories e.g.
- Running workshop with customer for upcoming feature (driven by Business Analyst with involvement from the rest of the team)
- System architecture design spike for upcoming feature (driven by external or team Architect with involvement from the team).
- Important tech debt story (requiring deep Database skills).
- Current feature story.
- Maintenance story from existing product.
- High priority support ticket for old product still supported by the team.
Setting one good Sprint Goal for this Sprint Backlog is not trivial even with a clear prioritisation. Selecting one specific goal could be demotivating for the team members not working on something related to the goal and not capture what the team is trying to achieve in the Sprint.
Making the goal too fluffy to cover more stories doesn’t make much sense to me as it leaves more up to interpretation.
Having 6 Sprint goals is clearly not an option either (if everything is important then nothing is – P Lencioni).
I usually try with getting the team to agree 2-3 goals for the Sprint, but I must say that the engagement from the team is usually low to moderate.
I've tried implementing Sprint Goals with my teams, but hasn't worked yet.
Rather than trying to push for the Scrum by the book, we do what works best for us and we get results that we and the clients want. Isn't this the main goal?
If you get results, definitely that is what matters.
Goals not working does says something about your situation, doesn't mean you must fix it.