Checklist for Better Goals in Scrum (Sprint and Product)

 

Overview

I’ve studied the goals for some time now and have come up with a checklist that can help you make better Sprint and Product Goals.  My list is more refined than the SMART goals you may know about. If you’re unclear on why goals are important, see my blog post on commitments.

I will focus on Sprint Goals as there’s not a huge difference when judging the quality of either of these goals.

First, you should read this blog (10 Powerful Questions to Create Better Sprint Goals)  to get an idea of the power of Sprint Goals. It’s a killer blog that’ll have you rethinking your approach to Sprint Goals.

 

The Checklist

So without further ado, here’s my checklist. 

Scrum Goals (Sprint and Product):

• Are the objective of the related artifact (Product or Sprint Backlog)
• Are aligned to fulfilling the higher-level goal
• Are achieved when (or before) the related artifact is exhausted
• Are observable when achieved
• Are Focused on enhancing value for the customer via the product
• Are outcome-based (not output based)
• Are generally singular – not compound
• Don’t assume future goals

As I explain the checklist, remember that it’s merely a tool to help you make quality goals, not a draconian doctrine you must follow. You can disregard one or more items on the checklist if it doesn’t make sense in your situation.

I will explain this checklist by focusing on Sprint Goals, but the general application works with Product Goals too.

 

The objective of the related artifact 

The Sprint Goal is the objective of the Sprint Backlog, not the PBIs within the Sprint Backlog – they are the plan to meet that goal. Similarly, the Product Backlog is the objective of the Product Goal. By objective, I mean the true purpose of the related artifact, which, when achieved, denotes that artifact as successfully completed. Not completing the objective means the related plan (artifact) was unsuccessful – we didn’t do what we committed to. 

One special case with the Product Goal: once it is achieved, the Product Backlog may have still exists and serve a new Product Goal.

 

Aligned to fulfilling the higher level goal

Achieving the Sprint Goal moves the product closer to the product goal. The product goal will move the organization closer to realizing (not necessarily achieving) a product vision.   Therefore, a good Sprint Goal can be seen in the context of its positive effect on the Product Goal.

A Product Goal can be seen in the context of the product vision or business vision depending on your organization’s product management approach.

 

Achieved when (or before) the related artifact is exhausted

It seems self-evident, but having a goal that can’t be achieved by completing the related artifact means the goal is too expansive. In the case of a Sprint Goal, you must be able to reach the Sprint Goal when you’ve completed the PBIs in the Sprint Backlog.

One caveat is that you may have PBIs in the Sprint Backlog that don’t contribute to the Sprint Goal – such as a PBI to correct a critical report calculation defect.  Therefore you can achieve the Sprint Goal but still have work (PBIs) in the Sprint.  A little bit of this is fine, but don’t make Sprint Backlogs filled with PBIs that aren’t related to the Sprint Goal.

 

Observable when achieved

The impact of the goal must be observable once it’s achieved. This doesn’t necessarily mean measurable or supported via some specific metric, but it means you can see the impact.  You need to know if the intent of your Sprint or Product Goal will actually provide some sort of value – through observation. 

There are well-meaning but wrong examples of goals: ones that include increasing sales, increasing customer satisfaction and retention, or system up-time are usually unsuitable for Sprint or Product Goals. That’s because you only know when customers are more satisfied after a release and the customers have had time to absorb the new iteration. Yes, we want happy customers, but typically Sprint Goals can only create an experiment to increase satisfaction along the related probe to see if that experiment was successful. Getting sufficient feedback will probably be done well after the sprint and, therefore, cannot be a Sprint Goal.

 

Focused on enhancing value for the customer via the product

Internally focused goals are not healthy. The goals should impact your customer and do so via the product. For example, increasing customer sales, increasing internal revenue, and reducing customer complaints are all examples of internally focused goals that advance the organization’s value, not necessarily value for the customer. Reducing complaints is excellent, but the real goal is to provide a high-quality, valuable product that gives the customer no reason to complain. 

Being product-focused means that the customer enjoys the enhanced value through using the product. Sprint Goals that reduce technical debt or use a new code library are usually internally focused. A Sprint Goal to update documentation is usually not related to the product itself and, therefore, a poor Sprint Goal.

 

Outcome-based (not output based)

A goal that looks for increased velocity or having more PBIs complete is output based. It’s better to get more value out of less. From a software standpoint, new code is both an asset from the value it provides but also a liability in that it needs to be curated. Getting more value from less software is better. Having goals that focus on getting more work done rather than providing more customer value are typically not helpful.

 

Are generally singular – not compound

There’s a delicate dance here between having a goal so vague that it’s not helpful and creating compound statements as a goal. Having “ands” in a goal, particularly a Sprint Goal, can lead to losing focus and less team cohesion. With such compound goals, a developer can focus on one part of a goal and not help the team with another part of the goal. While it may not always be possible to have a completely singular goal, you should not create a compound goal unless there are not many other options.

 

Don’t assume future goals

Does the Sprint Goal stand alone? If your Sprint Goal is only a step to the next Sprint Goal, there’s a good chance your goal isn’t providing much value as it should. If the current Sprint Goal only provides value by the completion of future sprints, you are falling into a waterfall mentality.

Certainly a Sprint Goal can fulfill a need that is further enhanced by future Sprints, but if the current Sprint Goal is just a stepping stone, make sure you don’t fall into a waterfall trap.

 

Advice

As George Box has famously said, all models are wrong, but some are useful. This checklist has been helpful for me and a lot of people I’ve coached. It’s imperfect, and some rules may have to be ignored. The purpose here is to guide you and let you decide if this model is useful. Good luck.

See my classes at www.suscheck.com