Product Goals, not Sprint Goals

Sprint Goals

Setting Sprint goals as targets are a popular way to focus Scrum teams to come together and strive towards a common purpose, specifically within the timebox of a Sprint.

There is a plethora of literature on why Sprint Goals are needed, the challenges teams face when coming up with one during Sprint Planning and the various nuances of what constitutes a good Sprint goal and what makes them weak.

However, if one were to step back and look at it holistically, it would become clear that Sprint Goals are totally unnecessary and are in fact a distraction. This begs explanation.

Product Goals

Let us start by considering the Product as a whole. It is imperative that we start with the product vision, as without a vision, there is no end goal and we would end up chasing our own tails. To achieve your vision, you need a roadmap. The Product Roadmap, by definition, informs the strategic approach to your product vision.

The product development team should be part of any conversations on product roadmapping and should collectively own this artefact along with the Product Owner. The Product Roadmap, in turn, guides the team in its product backlog creation and evolution.

By the same token, Product Goals are what you put on your Product Roadmap. Product Goals are like milestones on your roadmap. At any point in time, the next Product Goal is a single point to focus on for your teams. Product Goals are what your teams should work towards. For instance, if you put all your current work-in-progress on a kanban board, they need to be all towards the next Product Goal. Getting teams to focus on the Product Goals keeps them focused on the product. This creates shared purpose.

Product Goals will not all be the same size. Some will be easier than others to achieve. Some may take longer than others to achieve. For instance, some goals may be achieved within a Sprint, whereas others may take multiple Sprints to achieve. The point is that these Product Goals are worth achieving in terms of impact to your users, business and stakeholders.

Sprint Goals on the other hand, are goals crafted specifically for a Sprint. Let us consider an example:

One of the outcomes (product goals) we were working towards was the ability of our customers to ‘view, maintain and pay invoices’. Without these three parts together, we had determined that our customers would not get a whole outcome that they could meaningfully use. Each part relied on the other. Yet, since we couldn’t fit all of it into one Sprint, we built them over one and a half.

The Product Goal, ‘view, maintain and pay invoices’ if split into two Sprint Goals, ‘view and maintain invoices’ in the first Sprint and then ‘pay invoices’ in the next, then the second Sprint gets padded with other stuff that came next in the order, making the second Sprint Goal a hodge-podge of parts of two Product Goals.

There are many issues with creating goals for Sprints and setting that as the target for development teams.

Here are my top seven reasons why you shouldn’t use Sprint Goals.

1. Sprint Goals treat Sprints as Fixed Price Projects

Let us consider what the Scrum Guide says about the Sprint Goal:

The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal.
- Scrum Guide

If a Sprint Goal is an objective for a Sprint, then the Sprint becomes a project, a piece of planned work that is finished over the duration of the Sprint, with the Sprint Goal being the Project Objective.

By defining an objective for the Sprint crafted as a Sprint Goal and the Product Backlog items that, if completed would achieve the Sprint Goal, the scope for a Sprint is fixed at the beginning of the Sprint. As we should all know, fixing scope, schedule and costs is bad practice, as at least one of the three is bound to suffer.

2. Sprint Goals Guarantee Occasional Failures

While a team has the freedom to choose how they will achieve a Sprint Goal, it still doesn’t change the fact that a goal / objective agreed to by the team at the beginning of the Sprint is akin to fixing scope, leaving the team with the possibility of binary outcomes, either they achieve it or they don’t. This guarantees failure for the team at least some of the times.

Failure impacts trust and morale. Sometimes not achieving goals that were agreed to, affects trust with stakeholders. It also affects the team is many ways. For instance, the mood and morale of the team members may be less jubilant when they haven’t achieved a Sprint Goal in contrast to when they did.

3. Sprint Goals Promote Ebb and Flow, Creating Stress in Systems

Since software development is indisputably complex work, there are always unknown unknowns. It wouldn’t take much to agree with the fact that teams will find themselves under pressure, or on the other hand, having too much slack, as they go from Sprint to Sprint.

If a team achieves a Sprint Goal too early in the Sprint, or if due to pressure they start estimating conservatively, taking on less for the sake of predictability, then there is unplanned slack, an unevenness in the flow of work, or to put it in lean terms, Mura.

One will also find that teams guided by Sprint Goals are under pressure toward the end of Sprints as they frantically try to meet expectations set at the beginning of the Sprint. This is Muri, again in lean terms, an overburden that we can and should avoid.

4. Sprint Goals Force Upfront Designs

The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment.
- Scrum Guide

Although a detailed design is probably not the objective here, still an upfront design activity happens at the beginning of the Sprint. This comes at a cost of emergence and agility, although it can be argued that the length of a Sprint is short enough to call this design, just-in-time. However, this design activity is not forced by need, as in, it is time to design this part of the system; instead, this design activity is forced by the need to agree to a Sprint Goal at the beginning of a Sprint.

5. Sprint Goals Force Work Breakdown Structures

The Development Team usually starts by ... the work needed to convert the Product Backlog into a working product Increment.
- Scrum Guide

All the work needed to achieve the objective is figured out upfront, providing a plan to follow. This is a work breakdown structure with many teams figuring out task level details, dependencies, and even task level estimates, all for the purpose of monitoring progress towards  the Sprint Goal, forcing the team to deliver to a plan.

6. Committing to Sprint Goals Necessitates Change Control

If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint. - Scrum Guide

While "negotiate the scope" is left for interpretation, this still reads as change requests and approvals.

These negotiations with the Product Owner creates an ‘us versus them’ mentality. They are also unnecessary conversations that focuses more on how much is achieved in a specific time period, rather than on the product itself. This sends process kaizen, continuous improvement in process, down the wrong path.

7. Sprint Goal Forces Delivery to a Plan

"By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment." - Scrum Guide

Finally, the team is forced to a project plan to live by for the duration of the Sprint, and an implicit promise to get it done.

"The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog." - Scrum Guide

Measuring progress against a Sprint Goal focuses on delivering to a plan. A team that can consistently achieve its Sprint Goals is not necessarily the best team or building the best possible product. This is a wrong metric to measure for progress.

Some More Follies of a ‘Sprint Goals’ Mindset

A. "The Sprint Goal ... provides guidance to the Development Team on why it is building the Increment." - Scrum Guide

It is true that the development teams need guidance on why they are building the next increment.

Product Roadmap, Product Backlog and Feedback, (Not Sprint Goals), Give Guidance to Development Teams on why they are building what they are building.

As long as the Product Backlog is collaboratively maintained upstream with the development teams and they share the vision, the strategy and the product roadmap, the teams will naturally be guided by the product goals they are working toward.

B. "During Sprint Planning the Scrum Team also crafts a Sprint Goal." - Scrum Guide

If the Sprint Goal is crafted by the team during Sprint Planning, based on an Objective defined by the Product Owner, then the crafted Sprint Goal is merely paraphrasing the Objectives defined by the Product Owner.

For instance, it could be our goal to achieve our objectives that result in desired outcomes.

Let us consider the dictionary meaning of these words as published by Cambridge:

goal
noun
an aim or purpose:

• Our goal is for the country to be fully independent within two years.
• They have set themselves a series of goals to achieve by the end of the month.
• Do you think I'll be able to achieve my goal of losing five kilos before the summer?

objective
noun
something that you plan to do or achieve:

• Her main/prime objective now is simply to stay in power.
• Can the sales team achieve/meet its financial objectives?

outcome
noun
a result or effect of an action, situation, etc.:

• It's too early to predict the outcome of the meeting.

In effect, our desired outcomes could be rewritten as our desired objectives and vice versa or either could be expressed as goals.

Paraphrasing of Objectives into Sprint Goal for the Sprint during Sprint Planning is, to put it in lean terms, Muda, a wasteful exercise. It serves no purpose other than to fix expectations on what would be delivered in the upcoming Sprint, a useless and distracting metric.

C. "Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month." - Scrum Guide

This is a claim that by ensuring inspection and adaptation of progress toward a project objective (Sprint Goal), we can enable predictability.

Anyone who can successfully predict in software development is an outstanding oracle in the making. We may certainly reduce variability by reducing the scope and the schedule, in this case, a short time frame of one week to four weeks of a Sprint, instead of a six month or a twelve-month project. However, unfortunately, the Cone of Uncertainty still applies.

D. "The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives" - Scrum Guide.

The development team can work on one coherent function at a time without the functions having to take exactly the duration of a Sprint to develop. The development team continues on to the next coherent function, after finishing one. They do not have to work on separate initiatives at all.

E. Sprint Goals Are Based On Sprint Duration

It is great to have a shared purpose when working as a team. In fact that’s what makes a team a team, rather than a group of people!

A goal is an aim or a purpose. So we could represent our Product Roadmap as a set of goals we want to achieve.

These goals may each take different lengths of duration to achieve. These goals may not add up to, or each take the exact duration of a Sprint. In fact, these goals are not related to a Sprint in any way.  

Goals may be achieved before the end of a Sprint, or after. It should have no bearing on how the team works. On the other hand, a Sprint Goal forces an artificial deadline to achieve by.

Sprint Goal is a flawed concept. Instead we should embrace achieving Flow at a Sustainable Pace, delivering Product Goals, or Objectives, or Outcomes.

About the Author

Mahesh Krshnan is playing an advisory role at Grant Thornton, researching, writing and supporting leaders in the public sector with Agile Delivery assurance and advise on organizational delivery approaches to create a culture of safety and high performance.