In one of my latest videos, I talked about why setting goals (Sprint Goals or Product Goals) is a skill a Scrum Team needs to develop. One of the things I talked about was the usual challenges Scrum Teams face when creating Sprint Goals. Because it is so common, I’d like to give a quick rundown of those challenges and give you some insights into how you can help your team overcome them.
PRESCRIPTIVE SPRINT GOALS
Often when Scrum Teams start implementing Sprint Goals, they have a hard time achieving them. Of course, there might be many different reasons for why it is happening, however, if not a single goal is ever achieved, I would suggest looking at the goals themselves first, before trying to implement improvements in other parts.
A common reason for never beibng able to achieve Sprint Goals is that from the beginning they were not achievable, because they were too prescriptive.
“Complete Product Backlog items 1 to 5 by the end of the Sprint”
When it comes to complex work, such as product development, you can’t guarantee delivery because there are so many different factors that impact your work. In the same way, when a delivery goal is “too prescriptive” it can’t be achieved due to all the same factors.
Consider Sprint Goals that prescribe the list of exact deliverables to be guarantees. If you can’t in good faith guarantee that you will deliver something specific (“items 1 to 5) by the exact date (“end of Sprint“) with 100% confidence (commitment), then you shouldn’t create such goals.
Loosening up the deliverable
If your team is struggling with this challenge, one of the ways to overcome it is to make the success criteria less rigid.
Remove the list of deliverables from the Sprint Goal and instead ask the team to think about what value these deliverables would bring. Ask “Why do our stakeholders care about it?”
You don’t have to change the way you plan your Sprint right away, start with setting goals that provide flexibility first.
MANY SPRINT GOALS
One of the very common issues that I see in teams is that they cannot create a single goal, but instead create multiple ones.
This is often comes from the fact that the team members do not collaborate, and instead each work on their own thing. You might even see small sub-groups forming within the team.
This is a very bad sign and you have to jump on fixing it as soon as possible.
Start with “Why”
To quote Simon Sinek, “start with Why”.
If your team picks up work based on a certain set of skills they have, work with your Product Owner to understand bigger goals behind each Sprint.
Start every Sprint Planning with figuring out the goal first without looking at the Product Backlog. Do not review Product Backlog items to help you with your goal because it will create bias in team members minds and will lock them into thinking about “their” piece only.
You can ask questions around what stakeholders want the most, or what is the most critical piece.
Is your team really a team?
If in the end, your team can never-ever create single goal that would bring them together to collaborate, then I would have to ask if they are actually a team or just a group of colleagues who happen to work on the same product.
I talk a bit more about this topic in one of my earlier blog posts Same Product = Same Team: Myth of Fact.
NEVER-ENDING SPRINT GOAL
The last big challenge I want to cover here is about Sprint Goals that go on forever.
This usually happens when a team is creating once again and unachievable Sprint Goal and just keep pushing it to the next Sprint.
This is no better than having no Sprint Goal at all. It removes the sense of achievement (nothing ever get’s fully done). It kills motivation (what’s the point if I can’t succeed anyway?). It damages stakeholder confidence (this team can never achieve anything).
No goal is better than a bad goal
I would argue that having no goal at all is better than having a terrible unachievable goal. Having no goal limits the team’s ability to grow and improve. Having an unachievable goal actively damages the team.
So the first thing to do, if no other options are possible, is to remove the goal completely. If your team doesn’t want to remove it, ask “Will we achieve this by the end of the Sprint? How confident are you?”. When they answer “no” to the first question, or give you a very low confidence level, you will have easier time getting rid of the goal that doesn’t make sense.
The second thing to do, is to help the team create some realistic goals. Sometimes less is more. Ask the team what would be the very minimum that they are quite sure they can get done by the end of the Sprint and base the goal on that. Even if it is one single item from the Product Backlog.
