Release Goal & Sprint Goal — Effective Ways to Design

Problem Statement:

As a Product Owner / Manager,
I want to have clear release / Sprint Goals
So that team can be focused
And prioritization can be done better
And team delivers right value

The last couple of days, I was constantly reviewing Sprint/release goals and realize that it’s not that easy to define release/sprint goals effectively. I remember the days where I started my journey and defined sprint goals and it was just a statement and doesn’t look like a GOAL. Not motivating enough to accomplish.

• I thought to share my lessons learned over a period of time. It looks easy when we read about goals but could be difficult when actually put on the paper. We need to train ourselves. (Having said this, learning never stops & I am still advancing myself.)

What is Release Goal / Sprint Goal?

• Goals help us with planning. Goals drive the product backlog and the release plan, not the other way around. Goals drive what gets included in each sprint. A written down goal, if located in a public place, is a consistent reminder and motivation to the entire team.
• When we have the Release Goal defined we just have to break it down into smaller more achievable Sprint Goals.
• A sprint goal describes the purpose of a sprint. It provides a shared objective and states why it’s worthwhile undertaking the sprint.

Let’s make some examples.

Example of Release / Sprint Goal

Who Set the Sprint Goal?

According to the Scrum Guide:

“During Sprint Planning the Scrum Team also crafts a Sprint Goal.”

Thus, the Sprint Goal is determined by the Scrum Team. Product Owner, Development Team and Scrum Master together. I would stress out that it is joint responsibility but if we don’t see happening effectively then PO/SM needs to contribute to achieving this.

Why they matter/benefits? Why we need them?

The sprint goal will help you as a team:

• Stay focused.
• Define what is valuable.
• Determine priority.
• See progress.

If you are using sprints as a planning method, you should be setting sprint goals. The sprint goal is an essential part of SCRUM. Not using sprint goals will make you a ScrumBut. The Sprint loses its value as it is just a container of items. If we don’t have a sprint goal, Kanban will be more appropriate where there is no sprint (and hence no sprint goal).

OK, We know all these things then where the problem lies?

• To be honest, a lot of SCRUM teams do not set always proper sprint goals. To save time in a sprint planning meeting, stories are often pulled in based on urgency. But a backlog alone does not help explain why something needs to be done.
• Another challenge is that teams also commit to things that are not a part of the sprint goal. They might say that “yes, but we also need to do …”. However, promising too much and not delivering on that promise is a worse alternative. To multi-task is a productivity killer. Finish one goal before starting on the next.
• The goal is too broad and not value-focused.
• The backlog is not organized into value-focused Sprints.
• There is a disconnect between the product backlog and the product vision so the value of a Sprint is poorly understood.

How do You Write a Good Sprint Goal?

• Like any other goal, a sprint goal should be SMART: specific, measurable, attainable, relevant, and time-bound.
• Not over-complicate a sprint goal
• Make it visible. Write the Sprint Goal on or near the Scrum Board. Make it large. Use a color or border that stands out.
• Make it business or user-focused when possible.

Here are some examples of unclear Sprint Goals and modifications to make them clearer.

Clear Sprint Goals

The Sprint goal is typically defined in the first part of the Sprint Planning Meeting in the following main steps:

1. The product owner presents the ordered backlog items to the team.
2. The team discusses and understands the work for this Sprint.
3. Team forecasts and commits on the items that can be done.
4. The team creates the Sprint Goal for this Sprint.

Last but not the least, if we have created good release /sprint goals with great descriptions, they can be reused during the sprint review meeting, or various ceremonies and documentation will become more easier and sensible. No need to invent will again. :)

References:

The Product Owner's Guide to Effective Sprint Goals

What is a Sprint Goal?