1. What is a Sprint Goal?
The Sprint Goal is the goal that the Scrum Team needs to achieve at the end of the sprint, discussed and agreed upon by the Product Owner & Development Team during Sprint Planning. From Sprint Goal & velocity, the Development Team selects Backlog Items to perform in the Sprint.
A full Sprint Goal will answer 3 questions:
- Why do we need this sprint? (ex. to complete a function, to thoroughly address a risk).
- How does the project team reach the Sprint Goal?
- What metrics are applied to evaluate deliverables? (ex. if the sprint goal is to improve performance, which metrics should be used to assess whether the level of improvement is satisfactory)
During the Daily Meetings, the Development Team will continually inspect (check) progress against the Sprint Goal, detect & handle difficulties to maximize the ability to complete the Sprint Goal. It can be said that Sprint Goal is a guideline for Development Team’s activities & is the first measure to evaluate Team’s performance.
It should be noted, the Sprint Goal is a statement showing the value that the Development Team will achieve after completing the Sprint. Based on the Sprint Goal, the Development Team will select the Product Backlog Items for the Sprint Backlog. For example:
- Improve the detailed product page interface, the goal of increasing X% conversion rate
- Improve X% of page load time
- Building an automatic error system to improve product quality
Some other roles of Sprint Goal for Development Team
- Create certain flexibility: The Development Team does not need to complete all tasks in the Sprint Backlog to be considered to complete the Sprint Goal. During the development process, some tasks may take longer than expected, some other tasks are no longer suitable for the Sprint Goal; The Development Team can talk to the Product Owner to focus on the tasks that bring the most value, still ensuring the completion of the Sprint Goal even though the Team completes fewer functions than expected. For example, if the Sprint Goal is “Users can log in using Email & social network accounts”, the Team can still finish the Sprint Goal even though it is impossible to complete the Set a new password – which is included in the Sprint Backlog.
- Promoting teamwork spirit: With Sprint Goal, Development Team works & aims to a single goal, instead of following many requirements, functions & fragmentation activities.
- Keep the team focused: changes in the Sprint Backlog will affect the Development Team’s ability to fulfill the Sprint Goal. Therefore, when a change is required, the Development Team needs to investigate whether this change is necessary to complete the Sprint Goal. If not, the request should be included in the Product Backlog & evaluated later. This prevents the Development Team from being distracted by tasks that are not related to the Sprint Goal.
2. Difficulties and common problems when developing a Sprint Goal
a. There is no Sprint Goal, or Sprint Goal is a list of tasks to be completed
These are probably the two problems Scrum Team most often encounters. Sprint Goal example in the form of a list of tasks:
- Complete the function of login, search, and filter products
- Complete the tickets # 100, # 101, # 102
- Complete function A, & 3 critical bugs
As introduced in part 1, the Sprint Goal (1) is a statement about the value to be achieved after the Sprint is completed, (2) pointing towards a single goal, (3) defined in Sprint Planning. , The Development Team will rely on the Sprint Goal to determine the Sprint Backlog. A Sprint Goal like the example above will cause the Development Team to be fragmented (perform many functions in a Sprint), have a common voice, have difficulty promoting the teamwork, & guide the Development Team to work according to the task and plan (outcome -oriented) instead of value-oriented as desired by Scrum.
There are several reasons why the Scrum Team does not have a Sprint Goal, or a Sprint Goal in the form of a to-do list
- The product owner has little experience working with Scrum, or without product vision , does not really have the right to decide on the Product Backlog ; The Product Owner may only receive functional requests from other stakeholders & push to the Development Team in order of priority
- The Scrum Team is too big to be able to deploy one goal in a sprint, so the Product Owner must put many goals in each Sprint so that there is no redundant resources.
- The same Scrum Team works on multiple products and projects at the same time, making it difficult to identify the Sprint Goal
- Sprint length is not reasonable . The Sprint is too short for the Development Team to complete a Sprint Goal; or Sprint is so long that the Product Owner has to put many goals in each Sprint
- The Scrum Team is divided into Component Team (eg. Team Backend, Front-end, QA is 3 Scrum Team). At this time, accomplishing an objective requires the contribution of many Scrum Teams. Therefore, it is difficult to define a full, specific Sprint Goal for each Scrum Team
- In the Sprint Planning session, instead of defining the Sprint Goal from which to build the Sprint Backlog, the Scrum Team selects the Sprint Backlog Item that has sufficient velocity, and considers it a Sprint Goal. This is the opposite.
- Typically, the projects of some Scrum Teams do not work in the direction of creating value to be able to apply the Sprint Goal. For example, the IT Support Team is the daily operation, or the Development Team is in the product maintenance phase, the Product Backlog only has Bugs & customers require operation, no system development required. new.
Tips to improve this situation
- The Scrum Master needs to help the Product Owner build product vision & guide the Product Owner to build a valuable Sprint Goal
- The Scrum Master uses 9 Whys to help the Product Owner better understand the requirements and goals they intend to give to the Development Team
- The Scrum Master helps the Product Owner build a template to define the Sprint Goal
- Start each Scrum event by repeating the Sprint Goal
- Draft Sprint Goal for the next Sprint after collecting feedback from the Sprint Review
b. Sprint Goal is too big
Sometimes, in order to achieve the Sprint Goal, the Development Team needs to devote all its effort to implementing the Sprint Backlog & no more resources for any new sprint in the Sprint. For example:
- During development, some tasks are more complex than expected
- Some bugs on production need immediate handling
- A few members of the Team suddenly took sick leave
- The product owner requests that the “small” function be folded urgently as promised to the stakeholder
At this point, there is a high possibility that the Development Team will fail to complete the Sprint Goal. Tips to improve this situation
- Do the Backlog Refinement regularly to allow the Development Team to have a lot of time to learn Backlog Item before entering Sprint Planning, because many Backlog Items need time to study, can not give an accurate estimation in the timebox of a Sprint Planning meeting.
- Break back the Item Backlog, making planning & estimation more accurate
- While planning, always spend a part of your time in Sprint dealing with unexpected problems
c. The development process is not focused on the Sprint Goal
If only discussing the Sprint Goal during the Sprint Planning Session, the Development Team will easily forget about the goal, be distracted, & spend effort on the arising tasks that do not help them achieve the Sprint Goal as set out. After the Sprint Planning session, make sure all Development Team members are familiar with the Sprint Goal; The product owner can attach to the board, or document it to ensure the transparency of the Sprint Goal. In the Daily, regularly repeating the Sprint Goal, checking the work progress towards the Sprint Goal, optimizing the Development Team’s ability to accomplish goals.
d. Sprint Goal has no meaning, or is not clear
- Refactor front-end code (does not show value to users)
- Improve performance (no metrics to evaluate, no scope)
- Implement B2B purchasing flow (without scope)
An unclear Sprint Goal will make it difficult for the Development Team to determine when it will accomplish its goal, be easily distracted, and risk creating new tasks. A meaningless Sprint Goal makes the Development Team ambiguous about its work, difficult to engage with the product, and hard to find motivation to create value for end users.
Tips to improve this situation
- Need to build a Sprint Goal that is value-focused, more user-focused. The Sprint Goal should answer the WHAT question, instead of the HOW question
- Apply SMART criteria when developing a Sprint Goal (Specific, Measurable, Attainable, Relevant, Time-based)