"How do you write a good Sprint goal?" + 7 answers of our Agile Coaches #AgileSeven

We asked our Agile Coaches:

"How do you write a good Sprint goal?"

And they answered:


As the Sprint Goal is an expression of the shared understanding within the Scrum Team what is the next step the Sprint is trying to reach to move towards the overarching Product Goal. As such it is far more important to have a shared understanding in the team on what needs to be done and why. If this is achieved, formulating this into a nice sentence is just the cherry on top.

In my experience problems with formulating a Sprint Goal are more often than not a symptom of a lack of Focus in the team. Too many barely related topics are put into the Sprint ("they were at the top to the Product Backlog..."). Do not start with a list of things to be done and try to formulate a goal around it. Define the one thing you want to try next. Then just do it!

Avoid putting topics into the Sprint that do not work towards this next step just to ensure maximum utilization of all members of the team. Utilization is of no importance if you do not reach your goals.


The essence of a good Sprint goal is to align the team on what needs to be achieved. It needs to provide guidance when surprises or impediments happen and hard decisions have to be made. A Sprint goal should not just be “the sum of all backlog items in the Sprint” but rather communicate the process of how the product evolves increment after increment. So it is probably a good idea to roughly know not only the current but also a few upcoming Sprint goals. Personally, I like to think of a good Sprint goal as an achievement worth celebrating that can be demonstrated in the Sprint review meeting. With that goal in mind, the team works throughout the Sprint.


A sprint goal provides orientation and focus. It has to guide you in doing the right thing.

So when you plan your sprint start with setting the sprint goal. You build a shared understanding of the next version of your product. The sprint goal answers the question "What are you doing this sprint?". And the discussions about the sprint goal answer "Why do we want to build this?". Make it specific and be clear on what is the output you want to build. Be clear on the outcome you want to achieve.

In a second step pick the stories that need to be done to reach the goal. These stories are your priority. If a story does not support your sprint goal, think about postponing it. Think about slicing stories, so you are able to remove tasks and keep your focus.


More often than not I see projects where the Sprint goal is defined as a last step during the Sprint planning, trying to summarize the Sprint scope. Sometimes defining the Sprint goal might even be forgotten. This is not ideal. The sprint goal should support the enhancement of the product. It delivers guidance and support for the development to be aware of what they are trying to achieve and working towards. It helps the development team to keep their focus on what is important in case any unforeseen problems arise, impediments occur, or hard decisions have to be made. Ideally, the Sprint goals support the product vision and are iteratively guiding the path towards it.


First, a Product Goal is needed. It gives us the direction of every Sprint and its Sprint Goal. Every Sprint Goal should pay on the Product Goal. Every Sprint Goal should answer the question “Why should we invest time and money into the next Sprint?” (from a business point of view) and “Does it makes the product ‘better’ for the user?“. In the Sprint Review, we check if the Sprint Goal is reached. What helps us to define the goal? The SMART rule is great guidance. For beginners the definition is like a restaurant menu card (“main dish” plus 1 or 2 “starters” and “deserts”. If it is too difficult to find 1 Goal then it could make sense to shorten the Sprint.


Unfortunately, I’ve seen many teams were having a sprint goal that was more like a cargo cult and nobody really understood the purpose of a sprint goal. Therefore, first of all, one needs to understand why we have sprint goals in Scrum in order to write an effective sprint goal. If you don’t know yet, check out this 2 minute read about The 11 Advantages of Using a Sprint Goal. Having that said, I found two things very helpful when it comes to crafting good sprint goals:1. Again: Start With Why! Try to write sprint goals (“the why”) a few sprints ahead by decomposing your product goal and use those sprint goals to organize your product backlog items (“the what”) around these goals.

2. Express the expected outcome in your sprint goal. What will be different after completing the sprint? What will you learn? How will the behavior change of your users? Your sprint goal should answer these kinds of questions and not just express which features you plan to deliver. If you see the Dev-Team, Product Owner, and Stakeholders start talking about the sprint goal(s) in dailies, backlog refinements, and other discussions, you know your goals are more than just a sentence that needs to be written down once a sprint to follow the scrum process.


The sprint goal is to help the team to create a common understanding of what to focus on with the next iteration. It helps to get everyone focused, be transparent about what should be done within the iteration and can also help to lead discussions in the right direction.

A good sprint goal should be precise, easy to understand and describe a value for customers, users, stakeholders involved in the product that should be reached. There are different methods that help the team to formulate a sprint goal (e.g. SMART).

About #AgileSeven: We ask every month our Agile Coaches and will publish on the 7th of each month their answers. Why 7? It is a magic number.