How to create a good Sprint Goal

July 16, 2017

In this article I will try to explain why closely related stories and tasks, selected for a sprint, form a good sprint goal.


What do we mean by sprint goal?

Sprint goal is set by the scrum team. It means selecting the stories and tasks for the next sprint to implement and deliver. As we know from scrum, the event that this selection happens, is the sprint planning. There, the team discuss the candidate stories, trying to finalize them with the PO and also have some initial ideas of what means to implement them.


So a sprint goal, is represented most of the times from the sprint backlog. A list of a stories and tasks which when they are done, we can say that the spring goal is achieved. In order to create this list of things, the product owner must first bring higher in the product backlog these items, so the rest of the team can discuss it in the planning event. 



User stories is the form of the business requirements that scrum uses most of the times, to describe what needs to be done. With that in mind, a product owner can group stories and tasks, which, from business perspective, are closely related.


For example, let's image a "search flights" feature. The product owner can break this down to stories like:

As a user I would like to enter the departure airport and the destination airport and have results.

As a user I would like to enter the flight dates and search... and so on...


From the other hand, if the PO chooses stories for the sprint for different features, could have a negative impact. 


How it affects the Sprint Planning ?

To answer this, I would like to mention something which I believe it's common sense. Let's imagine a product owner in a planning meeting, ready to explain the list of stories he has in mind as the next goal.


If this list is assembled with non related things, switching context during the meeting, will cause not only frustration to him, but also to the developers who need to implement them. Also, the more "scattered" the list is, the more exhausted everyone will be after the planning meeting.




One of the things that it is noticed regarding the reasons of why a sprint fails, is the fact that the Product Owners fail to make developers understand what needs to be achieved.


Many teams fall to the trap that a sprint is just input - output without paying attention of what this input is. Of course everyone pays attention how small stories are in order to fit the sprint, but that's not enough. Stories and tasks should be closely related under the hood of a feature.


What is going into the sprint and how closely is related is the key for improvement in many aspects.


How it affects the daily stand-up meeting?

Daily stand-up is the formal meeting of scrum and the purpose is for the team to create a plan for the next 24 hours. That's fine. In my experience, when the team has no related stories and tasks, most of the times, the things that one team member says in the daily stand-up doesn't affect or interest the other team members.


I don't mean that this is 100% true, but the members who may be interested are those who are working in the same user stories or tasks. Or if a technical problem occurs, another team member who is more expert could help. That's OK, but we can do better.





If the team has a goal assembled by closely related stories (remember the example with the search flights), then probably whatever anyone says in the daily stand-up affects everyone. Most of the team members understand the impact of the sprint goal depending what's going on, on a daily basis.


Since almost everything is related, helping each other and creating a plan for the next 24 hours starts to make sense.


How it affects the Sprint Review?

At the end of the iteration, we have the sprint review event. In that event, the team presents to the PO and other stakeholders the output of the sprint. Again, it's much more easy to prepare, review and discuss user stories related with one business need rather than reviewing un-related features or parts of them.




If the sprint review is happening with a mindset of having indeed the intention to see working software and decide the next steps, then I cannot imagine how this could be done if many unrelated things are presented. I would suspect that this can happen but with no valuable input for the teams will be given in that meeting. It will look like a demo mostly rather than inspection and real discussions of how we move forward.


How it affects the team?

Finally I would like to mention how the sprint goal affects the team in general. Again, a "scattered" goal promotes individual work rather than team work. Meaning that since the team members work on isolated tasks, there is not much need for collaboration. If there is no collaboration, there is no team.

Peer "pressure" for results is fading too because the focus is scattered. On the other hand, with closely related stories, probably every team member is expecting things from another team member and that way, the discussions promote team work. 




One thing I have always in mind when I discuss about it, is that a scrum team cannot be considered as a group of people belonging in a department, where they pick tasks and try to implement them within the time limit of a sprint.


They should be like a small military unit trying to capture a hill (goal). If they don't cover each other and run together, the goal of capturing the hill probably will not be achieved.



Please reload

Featured Posts
Please reload

Nikos Raptis -
Agile Coach, Speaker & Developer

I'm a scrum master, speaker and software developer. I love Agile values and principles and...

Contact me

© 2015 Created by Nikos Raptis

  • Google+ - Black Circle
  • Twitter Black Round