Each Sprint in Scrum starts with Sprint Planning. The main purpose is to decide on a Sprint Goal (what the team will deliver) and what items from a Sprint Backlog they will take to achieve it. But while preparing and deciding on a Sprint Backlog can be relatively easy, deciding on a Sprint Goal that not only introduces focus for the team but also helps stakeholders better understand a tangible value they will get can be hard. However, working with Sprint Goals (in Jira and in general) is a powerful agile practice that is worth the effort. This post will help you understand:
A Sprint Goal is a single measurable and specific objective for the Sprint. The whole Scrum Team defines it during the Sprint Planning and it becomes a commitment for the Sprint Backlog by the Developers. Sprint Goal is part of the Sprint Backlog and, from a broader perspective, should be heavily influenced by the Product Goal.
Why there should be only one goal per Sprint? A single objective helps Developers to focus their attention on what they need to achieve during a given Sprint. In this regard, a Sprint Goal encourages them to work on a single objective together rather than on several ones separately.
What about more goals? Is it OK to have multiple Sprint Goals? Having two goals in one Sprint is not optimal. There is a risk that your team will experience decreased efficiency and performance, while the outcome might not be as well-considered as it should. And what if the Sprint Goal becomes obsolete when the Sprint is already running? In such a situation, the Product Owner has the authority to cancel the Sprint.
Let’s say that you identified one goal and the whole team agrees on it. The next step would be implementation—Developers pull tasks from the Sprint Backlog and execute them one by one. Over the course of the Sprint, the team holds regular Daily Scrum meetings to inspect progress toward the Sprint Goal. When the Sprint is about to end, they check and validate if they met the goal (e.g., by running a product demo or a usability test).
The goal is a Scrum term, whereas the objective originates from SAFe®. Scrum recommends one goal per sprint and SAFe® allows for several objectives per sprint. Nowadays, both terms tend to be used interchangeably.
In Jira, you can plan current and future Sprints. The process of planning involves three main steps:
When you create a Sprint you add the Jira Sprint Goal. Simply, type in the goal and it will appear under the Sprint name.
If you have already created your Sprint but forgot to add a goal, you can still do it. Navigate to your Sprint backlog and click on the 3 dots (…) on the right hand-site of your screen. Next, click on the Edit Sprint to name your current Jira Sprint Goal.
Jira Backlog panel. You can see the Sprint Goal (“Customers can pay for the flight tickets with PayPal”) under the Sprint name (“CA Sprint 1”).
Moving on to the Sprint board where you view your current Sprint. To assign individual issues to it, you can search for them using JQL and then add them to the Sprint. Or you can drag an issue from the backlog directly to the Sprint (in the Jira Backlog panel).
Consequently, once you populate your Jira Sprint board with issues, it will look something like this:
Jira Backlog panel. You can see the Sprint Goal (“Customers can pay for the flight tickets with PayPal”) under the Sprint name (“CA Sprint 1”).
For this Sprint, we created 15 issues. But as you may have noticed, even such a small amount of issue cards does not fit on a screen. What if you have, for example, 5 teams of 4 members, where each of those members will work on 3 tasks? The result gives 60 tasks for only one Sprint.
Now imagine that you have planned more Sprints ahead, which only adds up to the total amount. So the bottom line is that the Jira board’s vertical layout does not have enough room to allow comfortable tracking.
The conclusion is that when you only plan for one upcoming Sprint for one team, plain Jira might prove effective. But with more than one team, and long-term budgeting and planning, you probably need to extend Jira with another tool to work more effectively.
Sprint Goal tells your Developers what they should focus on. It also serves as the reference point against which you can validate whether the Sprint was successful. Therefore, it is crucial to keep up with your teams’ progress to ensure they meet the goal within the prescribed Sprint duration. You can do it by adding the BigPicture app to your Jira.
BigPicture is a powerful PPM software that lets you visualize your backlog and Sprint Goals. This way, you and your team have a clear overview of all the tasks they will be working on. You will also be able to see how the tasks you have planned support your Sprint Goal and track their execution progress.
With the BigPicture’s Board module, you can break down your Sprint into teams and assign them tasks. Or, simply drag and drop tasks from the backlog list (right side) onto the board (left side).
Board module in BigPicture. The backlog list items you can add to your team with a drag-and-drop feature.
You will see all of your teams on the same board. Here, you can also manage your teams by adding a new team, duplicating the existing one, or assigning a team to another board. And if your Sprint involves several teams, simply collapse and expand the views. This way you can focus on the progress of each team individually.
Collapsed views for teams: Craftsman, Native Features, and Tools4you, as well as for the Unassigned tasks.
Since your whole Sprint fits on one board, you can easily create dependencies between two tasks that belong to one team, or two different teams; or two different iterations; or two different projects.
BigPicture supports cross-project dependencies and you can add interdependent tasks from other projects to your Sprint board, too. As a result, you can view all the tasks you care about in one place.
The Roadmap module allows for setting objectives that you can later show or hide on your Sprint board.
You can set different objectives —not only on the Sprint or team levels but also on the Program Increment level.
On top of that, if you need to set multiple goals for a Sprint, then it is possible to do as well. Let’s say you planned 3 goals for a Sprint for a given team. The team completed 2 of 3, which means that you mark those two Sprints as “completed,” whereas the third one as “failed” and move it to the next Sprint.
Each task that your team finishes counts toward the overall completion of the Sprint. BigPicture displays the progress in percentages and bars.
The Craftsman Team completed 4 tasks out of 14 which means they completed 29% (percent) of their work. Similarly, you can see the progress of other teams.
Every Sprint Goal should be short (ideally, a one or two-sentence statement) and easy to understand. Good Sprint Goals not only inspire teams but also help them self-organize around a single objective.
From a business perspective, Sprint Goals are unique because they depend on the individual business context—Precisely on the Product Goal. Consequently, Sprint Goals represent the next most valuable outcome toward the Product Goal.
So how do you write good goals for your Sprints?
Like any other goal, a Sprint Goal should be SMART (Specific, Measurable, Achievable, Relevant, and Time-bound).
The goal should tell you what is waiting by the end of the road. In other words, it should explain what you are trying to accomplish.
When the Sprint is over, you should be able to measure the results. For that, you may want to define some standards that will let you assess the end product.
Being ambitious is fine, as long as the goals you set are realistic. So before your team commits to anything, make sure there is enough time and resources to carry out the work.
Sprint goals and business goals should be hand in hand. The value the goal represents should indicate what positive impact it will cause on the stakeholders, including the users.
Deadlines in Sprint are natural—each Sprint has a clear start and end date. Timelines help teams commit, focus, and work at the same pace.
What could constitute a Sprint Goal that, on the one hand, is specific enough to let the team understand what they should focus on, and on the other—its value could be measured? Let’s take a look at a few examples:
– An example of a Sprint Goal in a software development context is delivering a feature. The value of new functionality is that it allows users to perform actions that did not exist before the feature release.
– Agile marketing teams could establish their Sprint Goal to be about risks by addressing an issue, such as broken links, low landing page conversion rate, performance, or security. The value would be an immediate better user experience, more secure data handling, or more customers signing up for a demo webinar.
Anna-BigPicture
Project Manager
Appfire
Poland
104 accepted answers
2 comments