One of the 5 values of Scrum is Focus. Too often, I will ask Product Owners "What is the goal of this sprint"? Their response? "To get all of these Product Backlog Items done!" (and they look at me like...duh!)
My question is focused on ensuring that our Development Team has some semblance of focus for the Sprint. Most of the time, the Sprint is just a list of Product Backlog Items (in shotgun effect) that the Product Owner provides to the team. Then the team ends up assigning Product Backlog Items to each Development Team member (a separate problem we will talk about later, Product Backlog Items should be assigned to the team, not an individual).
So...what is a Sprint Goal? By definition in the Scrum Guide, it is the following:
"After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment."
This means that the Sprint Goal should be a short description of the objective of the Sprint so the Scrum Team understands the objective of the Sprint. The Product Owner is a large part of the driver of this Sprint Goal. The team uses it to have a shared and unified understanding of the goal. The more important part is the "why". It is often hard to pinpoint the focus of the Sprint and there in lies the problem.
Focus means that the team should have some semblance of "large rocks" that they are trying to get done in the Sprint. They will have other things that are a bit smaller that they might work on as well (that fall out of the Sprint Goal), but they do need that Focus that we can work towards as a team during the Sprint.
For instance, if our Development Team is working on an eCommerce web site, the Sprint Goal might be something like "I want to see basic shopping cart functionality; add, remove, and update quantifies". So the team will select Product Backlog Items that match up to that goal and decide how much of it they can complete in the Sprint. That will allow the Product Owner to answer the business stakeholders or even customers when asked "what is the team working on this sprint?". Instead of saying "the team is working on JIRA 482, 212, 283, 382, 12, and 7", they are able to say "The team should be able to show us the basic shopping cart functionality such as add, remove, and update quantities".
The Sprint Goal will also help us understand if we are taking in changes that might endanger the Sprint Goal. Once the team has forecasted the Product Backlog Items for the Sprint; Scrum states there should be no changes to endanger the Sprint Goal. So if we want to change the submit button from silver to orange, we can ascertain if that is a change that would endanger the overall Sprint Goal (which most likely it is not).
The Sprint Goal charts a course for the Sprint, allows the team to focus on rocks for the Sprint, and allows us to communicate with our stakeholders. Next Sprint Planning session; try it out. Have the Product Owner deliver a Sprint Goal, the team then selects PBI's to meet that goal, and then communicate the goal to the stakeholders. This helps drive clarity into what the team is working on and helps provide focus for that team.
A shared understanding of the Sprint Goal is key to being agile.
