Scrum has evolved over the course of 25 years, which is expected. It is a great testament to the meta inspection and adaption that it represents. With the recent evolutions, a clear emphasis on Sprint and Product Goals came to light in the Scrum Guide. And while some celebrated, others got extremely uncomfortable with this change.
Sprint Goals are not new and a big part of the community was already using those. I am 100% in agreement with the thinking behind them and I coach teams and individuals to organize their sprints in that way. In this post I will share with you what are the benefits I see with Sprint Planning.
Goals take you away from the slavery of task & TO-DO lists
So your team selected stories or tasks for the Sprint and that is great: you need to understand the work and the boundaries of what you are delivering and that work should be small enough to be completed in a sprint.
But you should be careful to have a meaning in all that. It is all too common to see teams doing tons of tasks that have no connection with each other and in most cases the sprint becomes about delivering all or nothing. And even if all the tasks are finished in the end of the Sprint, what is exactly the accomplishment of the team? 10 different tasks and stories might be too small to hold a meaning in itself if they are all disconnected pieces from several features of your product. Tiny changes on all your features? They might all hold value, but it would be a case by case to identify that value.
Some people challenge with the “Why Sprint Goal if I have a Sprint Backlog?” and I like to think one feeds off the other. But while it might feel great to check the boxes of all the things we do, and humans crave the feeling of completion and accomplishment, what are we then committing to in the end of that sprint planning if there is no unifying goal for the Sprint Backlog? What kind of focus do we expect to have throughout the sprint when blockers and problems start to arise? Focus and Commitment are Scrum values. User stories, sprint backlog and etc. are techniques and practices. Which one should hold more true to effective Scrum?
Be outcome oriented with goals
Then behold the Sprint Goal as a tool to help the team to maintain focus and have a solid point for commitment. Having a goal means that most of the tasks and stories selected for the sprint are interconnected to a bigger value, a direction, an outcome. It gives the team the ability to do something important which is negotiate scope. While sprints protect the team for most of the change, unknowns and last-minute changes will happen and the carefully crafted user stories might also be impacted. Embracing change over following a plan is a much underrated Agile value that is at stake and is beautifully honored by setting a goal for the Sprint.
Now, you might be thinking that sometimes we put things in the Sprint Backlog that just are not interconnected because between a new feature and some technical debt both must be done to be able to hit some target date. Fair enough and you are absolutely right.
Not everything holds the same weight
So it is fair to have items that might even seem disjointed in your Sprint Backlog. But a reality of life is that not all that we do has the same importance. Not all stories and task hold the same weight. They were all ordered in the Product Backlog, which tells us right away their relative importance to each other. And mind you, our goal might be “To catch-up with the technical debt on our report engine” and we can still have some stories about the new “Profile page” feature. But by knowing what is your team goal for the Sprint you know where to focus, what work on first and what let go if time does not allow for all that Sprint Backlog to be finished on time.
Goals help you see what are true blockers
Another reality is with the Sprint Goal clear and visible not all the issues we find during the sprint become a blocker. That’s right, we love to talk about handling impediments, clearing blockers, and all that is work in itself. Much of that is in the Scrum Master or Product Owner to solve when it is about priorities, delays, inter-dependencies, stakeholders. Scrum Master and Product Owner are single individuals, which can just create bottlenecks.
Blockers and impediments are so just in contrast with the priorities of the Sprint. And the Sprint Goal makes it clear. Whatever attacks or hinders the Sprint Goal should be dealt with. Whatever doesn’t, can wait. It is just a matter of effective work flow: if you have to solve all the problems, suddenly everything became a priority once again.
So, with proper goals in place you have a better chance at committing on solid grounds, staying focus through the sprint.
Edge cases
Of course there can be exceptions. Keyword being exceptions. If the norm is to not craft a Sprint Goal, I’d say your team is missing out on a great element of effectiveness. But it can happen. I can share with you here some examples of what I’ve been through with my teams and how we got around the apparently disconnected Sprint Backlog and still crafted a goal that helped us be on track.
Edge case 1
A Sprint where we basically had a lot of defects to cover. This was a Sprint dedicated to quality. And the defects selected were not randomly selected: they had the most impact on usability. So the goal of our sprint was “To make the user experience smoother by finishing our S1 defects”. Why is this an edge case? Because you should not be in a situation of having so many defects that you need to dedicate a sprint to fixing them. It hurts the Agile principles of technical excellence.
Edge case 2
A Sprint where we had lots of things to finish for the major release of our product and they were mostly omissions and things we had no time for before. This was basically some sort of “tiding up”. We established as a goal to “Complete a successful major release”. What makes it an edge case? Your feature should not have missing pieces, although it happens more often than we like to admit and it if happens too often it becomes what folks like to call a “hardening” Sprint. This makes one think why certain things (tests, infrastructure, etc.) were not built-in in the first place. Great retrospective theme.
Edge case 3
Non-software development teams usually service a lot of clients with competing needs. I had a Communications team need to finish proofing for one client and writing copy for another, which created subsections in their backlog (also Agencies and Marketing, Compliance, etc. are such types of teams). We came up with the goal of “Proof-reading for Client Z” because they were more advanced in their delivery and were also a more important client. Our copy writing client became a stretch goal and we still made some good progress there, but not all stories were finished. What makes this an edge case and therefore an exception that should not be occurring? I would challenge that this team still needs a backlog in an ordered fashion because there is always something more important be on time of money, even if it is from different clients. If this becomes the norm and too much parallel work keeps happening, is this even a Scrum Team with a clear mission?
What do you think?
Nothing replaces the Scrum fundamentals and its values and that is what I use when some sort of judgment is needed. Very few things on team dynamics and work management are by-the-book or obvious.
I consider staying true to mindset and behaviors something key on my role as a coach and that is why with Scrum teams I strive to inspire them to always craft a goal. I also know they are the team and they have their own learning to do and they win and lose by their own actions not by what the coach says.
And you? Where do you stand on crafting Sprint Goals for your team?
