Having a Sprint Goal in some cases is not easy. Having a good Sprint Goal is even more difficult. It has proven to be a difficult topic for many starting teams. There already are some good blogs on this, so I encourage you to search further through the Scrum.org resources after this read. In training and in practice I still often hear: “in our case, defining a Sprint Goal is not possible because <reason>.
Scrum Masters, this is your cue. “A Sprint Goal is like a canary in a coalmine.” It signals very early if something is wrong with regards to delivering value. If you hear your Product Owner, a developer or yourself saying this, it means you have found a possible impediment towards delivering value. Reframe this from ‘Sprint Goals do not work for us’, to ‘Sprint Goals do not work for us yet’. Instead of saying: “defining a Sprint Goal is not possible because <reason>”, you could say: “defining a Sprint Goal is not yet possible because <problem to solve>”.
As a Scrum Master, you are there to help your team and organization solve this issue. Chances are you will find some hidden gems in your use of Scrum in doing so. You might find out that some of the other challenges you face in applying Scrum, suddenly seem less prevalent. You might experience more engaging events as well as more focus and commitment of everyone involved. Don’t take my word on this, but try it. When exploring the possible problems to solve, they often fall somewhere in the following categories.
Our team is not really customer-centric. We are not delivering end-to-end features. Instead, we deliver a part of the system to another team that builds upon this. Then a separate team integrates the whole. In other words, we are a component team. It is hard to create an engaging goal around a technical component! The structure of your team might be the problem to solve, you could start a conversation with management on this.
Our Product Owner does not have a clear objective for the Sprint. He or she has many different stakeholders that demand different things. There is a lot of pressure from the business to deliver. It is hard to say no to the business, since everything is really urgent. In other words, the person that should be the captain is still a receiving Product Owner instead of an initiating Product Owner. Maybe the mandate or the lack of a vision or strategy might be the problem to solve.
Our Product Backlog has so many different projects, epics, themes and different parts of the product on it, there is hardly any cohesion. On the very top of the Product Backlog there is work for X different Stakeholders and for Y different features. It is important that we make progress on all these elements. In other words, we focus on making progress and keeping busy. We start early, but finish late. Often the things that feel fast, are actually slowing us down[i]. Maybe the structure and order of the Product Backlog might be the problem to solve.
Our team actually needs to deliver multiple items over multiple Sprints in order to create a full solution. First we need to do some analysis in a Sprint, then we can create the user stories for development. For our product we first need to create the database and then we can deliver the logic. Finally of course we need some UAT stories in order to finalize the feature. In other words we are slicing horizontally. Maybe the way you breakdown your work in phases and components is the problem to solve[ii].
There might be multiple challenges for your team and product. These categories might not be an exhaustive list. However, hopefully you can apply the “What is your reason problem to solve for not having Sprint Goals?” to find your challenge. Solving that challenge structurally, might require structural change. I would encourage you to go for it, try it, learn from it.
There is also something that could help you get there more gradually. Something that you – with your Product Owner – can start working on directly. Some easy wins might come from creating more focus on the Product Backlog. In essence, you have to start doing less things in parallel:
- Work for less stakeholders at the same time, just to show you are making progress.
- Do less epics, projects and features in parallel.
- Start less stories or items in the Sprint at the same time.
- Work on some items together instead of everyone doing their own ‘item’.
- Stop working on many different tasks in parallel, because ‘they look like each other’ or ‘you got stuck’ in one of the tasks. Start finishing tasks and resolve your bottlenecks.
By limiting the amount of different things you work on at all levels, you create focus. Focus on getting things done, on collaboration and on results. Let this be a big step towards creating a more cohesive Sprint and hence creating a proper Sprint Goal.
Special thanks to Wilbert Seele for the analogy of the canary, and to Guus Verweij and Guido Boskaljon for inspiration and input from our PSM II classes together.
[i] https://hackernoon.com/feels-like-faster-vs-makes-us-faster-828686facc7e?source=rss----3a8144eabfe3---4
[ii] https://agileforall.com/resources/how-to-split-a-user-story/