What Product Owners do wrong with Scrum Sprint Goals and how to fix it.

Sprint goals are there for a purpose — don’t treat them as an afterthought!

I work on a lot of projects, Some use Kanban, some using Scrum. All the projects are supposedly agile. As a result, I see a lot of good practice and probably an equal amount of poor practices.

Here’s something I often see on Scrum projects. I bet you see it too and, for Product Owners reading, have probably done it as well. It’s OK, you’re with friends here.

Here’s how it goes…

The Product Owner is often a bit pushed for time when it comes to writing the Sprint Goals. Let’s face it, they’re busy people and preparing Sprint Goals is something that tends to get pushed back.

This is Joanne. Her Sprint Planning session starts in 5 minutes and she’s just found the time to write her sprint goals.

So, given a rushed Product Owner who needs to create some goals, what happens next?

Well, it’s easy, they look at the progress so far and add a bit, coming up with some words based on where the project is at.

There you go — job done.

For example, if we’re working on delivering an initial iteration and it needs finishing next sprint, they’ll said “Finish the initial iteration”. Or maybe the iteration wasn’t completed because some testing activities didn’t complete in the previous sprint; easy, let’s just have a goal to “Finish the testing of the initial iteration”.

As another example, maybe there’s a big presentation that needs preparing and delivering; great, let’s have a goal to “Present to the managers conference”.

The problem is that these goals don’t do the thing that goals should do…

Why?

Well, goals in Scrum are supposed to deliver something of value to the business, not just something of value to the project. Scrum works on the basis that each iteration edges the business in a direction of increasing value.

In these cases, the goals are focussed on the things that the project is doing, or needs to do, rather than the reason they’re being done.

Now, you could get into using the templates for sprint goals that you can Google, and these are great because they tend to bring in measurability[1], or you could just start with working the business value in as a first step in the right direction.

Let’s have a go at rewording the first one and the last one.

“Deliver a first iteration of the product that we can show it to potential customers.”

“Help our manager’s conference to understand our project, how it will help them and the support we need.”

These are, I think better, because they are less about the project and more about the business who’s paying for the work.

Why bother?

Well, it means that your Sprint Review will be simpler because you don’t need to explain to your stakeholders what they’re getting for their money. You can literally just show them something in which they will see value.

I think it also helps the project team to engage with the business reasons for the work they’re doing, which generally means the team feels more involved and invested in what they’re doing.

So, next time you see a rushed Sprint Goal, have a go at working in the business value and see the value for yourselves.

This was written for my Substack, “Thinking Business”, where I explore business analysis and agile software delivery subjects.