It is a well-known fact that having a goal defined helps to accomplish it. A written down goal, if located in a visible place, is a consistent reminder and motivator. It is a public demonstration of internal desires.
Goals help us with planning. When we set a goal, we tend to plan our steps toward it. It makes even the most ambitious goals easier to accomplish. And probably that’s why we keep setting them up.
It is harder to abandon a goal which we have shared with others than one which we kept for ourselves. For example, it is not my first attempt to start a blog. The first I have been doing only for myself, and after two posts I have stopped. This time I share my idea with several people and they keep asking me when will be next post – so it makes me more motivated to continue.
The Sprint Goal
The Scrum also use this concept and has a Sprint Goal. In the Scrum Guide it is described in the following way:
The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment.
According to the Scrum Guide the Sprint Goal is set during the Sprint Planning. So It means that it is created by the whole Scrum Team.
I have heard about two approaches to define the Sprint Goal:
1. Short summary as the Sprint Goal
The team creates one sentence (or more than one) which summarise all or significant part of the work (functionalities) planned for the next Sprint. Let’s say that Sprint Product Backlog contains the following items:
- As a User, I’m able to share information about selected pages via Facebook.
- As a User, I’m able to share information about selected pages via Twitter.
- As a User, I’m able to share information about selected pages via Google+.
- As a User, I’m able to share information about selected pages via LinkedIn.
- As a User, I’m able to see the last login date.
Then the Sprint Goal might be: “User should be able to share information about selected page via social media“.
2. A selected Sprint Backlog Item becomes the Sprint Goal
During the Sprint Planning, the team decide which Sprint Backlog Item is the most important and treats it as a Sprint Goal. The purpose of the Scrum Team is to provide value with each increment (Sprint), the decision which Sprint Backlog Item should be the Sprint Goal might be based on the value it has for the product.
In this approach, the Scrum Team plans its work to first accomplish its Sprint Goal and then the rest of the Sprint Backlog Items. I’m not sure if this is a perfect solution because all Sprint Backlog Items should be delivered. However, in case of something goes wrong (one or two developers get sick) we don’t have to think about which we should focus. The Goal is already there.
I like both of those approaches. But most of the teams I worked with used the second one. Unfortunately, I have to admit that some of the teams I worked with decided not to use the Sprint Goal at all. Are those teams still using the Scrum? It’s not for me to judge.
Once the Sprint Goal has been set, the Scrum Team should monitor it. One of the reasons for cancelling the Sprint is when the Spring Goal becomes obsolete.
A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change.
Let’s make some example. The Sprint Goal says: “User should be able to login with a Facebook account“. The Sprint Backlog has following items:
- As a User, I’m able to create an account using Facebook.
- As a User, I’m able to match my Facebook account with my existing account.
- The system present information if User used Facebook to login.
Assuming that for some reason Facebook decides that they no longer support this functionality, or they introduce some unreasonable costs for using it. In that case, from the business perspective, it is no longer useful or profitable to introduce such functionalities. Since it is a bad practice to change scope while the Sprint is in progress, the Scrum Team can cancel it with Product Owner’s consent.
The Release Goal
If we have a Sprint Goal why won’t we create a Release Goal? I think it is a great idea and practice which might provide guidance to the Scrum Team planning their work. When we have the Release Goal defined we just have to break it down into smaller more achievable Sprint Goals.
Let’s make some example. The Release Goal might be: “User is able to pay for the appointment for a selected date“.
- Sprint 1: “As an Owner, I’m able to define time slots in which I’m available for consultations“.
- Sprint 2: “User is able to request an appointment. Once confirmed or denied by the Owner, User should receive a proper e-mail notification.“
- Sprint 3: “Following defined rules system should automatically accept or denied user request for the appointment“.
- Sprint 4: “User is able to pay for the appointment using PayPal service“. Of course, the last Sprint planned for the release might share the same goal as a release have.
The same as for the Sprint Goal, we can have the same two approaches for the Release Goal. The Scrum Team might select one of the Product Backlog Item or write a short summary of the work that needs to be completed.
In my honest opinion if we have the Release Goal defined we can easily monitor if the release becomes obsolete or not – the same way we do it for the Sprint Goal.
Tips & tricks
I’ve mentioned in one of the previous posts (LOL: it’s the second one) my favourite tool for running Scrum is JIRA. So I would like to share my idea on how to define the Sprint Goal using JIRA.
Last year Atlassian introduced a new functionality into JIRA Software Cloud which allows the Scrum Team to define the Sprint Goal. They have added an additional text field. Information stored there are presented below the Sprint Name. Unfortunately, this functionality is only available in Cloud version.
If you are using Server version, there is a plugin which helps with Sprint Goal. With this plugin, you will be able to add free text (with simple WYSIWYG editor) and add images. All stored information is presented below the Sprint Name. In comparison to other plugins, pricing for this one is OK. Even if you run instances with 250 users (or more). Unfortunately, you can install this plugin in JIRA Software Cloud. It is available in Server instances only.
There are some ways to maintain the Sprint Goal with default JIRA’s functionalities. Bellow tricks work on both JIRA Software Cloud and Server.
The simplest solutions for the Scrum Teams using a selected Sprint Backlog Item as the Sprint Goal are:
- The Scrum Team can add a prefix to the ticket summary. It might be “[Sprint Goal]“, “[Goal]” or just “[G]“. It can be anything the Scrum Team decides. It might look like: “[G] As a Scrum Master, I’d like to be able to store the Sprint Goal“.
The ticket summary is visible everywhere in JIRA (but at least it’s a beginning). It is also possible to filter/search tickets which starts in a specific way. - A label can be added to a selected Sprint Backlog Item. In a board configuration, there is a section (“Card colours”) allowing to assign a colour to tickets which meet search criteria. The outcome of this will be the Sprint Goal highlighted with the selected colour (thin colour line on the left-hand side). As the label has been assigned filtering and searching is quite easy to do.
- The most obvious solution is to create a new ticket type. That solution will handle both mentioned approaches. New ticket type should have the same options as most of the Sprint Backlog Items have: same workflow assign, same permission, etc. When creating a new task, there is the possibility to add a custom icon. That should make the Sprint Goal very easy to spot out.