Sprint Goals

When is a Sprint a success?

Let me cut to the chase and offer the following as a definition of a successful Sprint:

A successful Sprint is one where an increment of significant customer/user value has been sustainably delivered in broad alignment with what the team had forecast that they would deliver. As a consequence of their work they now have a better understanding of their problem-domain, and of their next steps. Additionally, the team have agreed what they will do differently (improve) to try and increase the likelihood of success in their subsequent Sprint(s).

Success criteria for a Sprint is something that I have discussed more times that I can keep track of. From interns and graduates fresh out of university to seasoned C-level managers, everybody seems to have their own idea of what 'success' looks like in Scrum.

Probably the most commonly cited definition is that 'every card brought into the Sprint in Sprint Planning is done'. I think that this viewpoint revolves around the common misunderstanding that the Sprint Backlog is a task list, and therefore the definition of success is coupled to that list being completed.

That's a kinda scary definition, because it inverts the first principle of agile software development by suggesting that following a plan is the most important thing.

Another common angle is that 'success' means that the Sprint Goal is done. I greatly prefer this over the previous definition; a well crafted Sprint Goal ensures that there is flexibility in scope, but also provides a 'guarantee' that value in being delivered to the user/customer. If a team is achieving this every Sprint, that is a typically a pretty good sign for the health of the team, and the project. But it is definitely not the only sign of success.

For example, imagine a team that takes on a hugely complicated/complex Sprint Goal, and delivers all bar one very small part of it. Perhaps it is a global product and they managed to release an industry-changing new feature in all bar the smallest of their supported markets. This is probably still a triumphant victory for not just the team but their wider business. If they had taken on a smaller goal which they did get completely 'done' but made no material difference to the business or industry, would that have been more successful? I think that we'd all agree not.

The purpose of a Sprint is to give teams a chance to creatively solve complex problems. It's an empirical process which means it all revolves around inspection and adaption.

This starts to highlight the problem with having black and white 'success' criteria. In a complex domain, we cannot [reliably] predict the relationship between cause and effect. In other words, we can't know before we start exactly how things will unfold. It's like trying to define success for each and every child, before they are even born.

Our definition of success really needs to acknowledge the uncertainty that has brought us towards an empirical agile process, rather than a tightly defined (more waterfall) one. This takes us to where we started this post, with a definition of success which can be applied uniformly and crucially explained to key stakeholders like management.

Your Sprint Goal still matters, but I think it is for the team to define and understand exactly what it means to them. The Scrum Guide says it "…is an objective set for the Sprint that… provides guidance to the Development Team on why it is building the Increment", and I think that is a pretty good starting point.

If you've got a different (or more concise) definition of success, please comment below.

What you commit to in a Sprint

There is a lot of confusion over what a team commits to when they start a Sprint, and particularly the role of the Sprint Goal. I've previously covered that in longer posts, but the metaphor below may help to 'connect the dots' in a simpler way.

Think of it like hiking through the countryside. You choose a place where you want to camp at night on your map. Getting there is your goal, and you must get there before nightfall (i.e. a timebox).

You don't want to necessarily have to plough ahead at full speed without breaks to get there before nightfall, so you build in a little bit of slack time. You know from experience how often you need rest stops, or want to stop to look at scenery, etc. and you know roughly how quickly you can travel over the type of terrain that you expect to face.

You probably have a route in mind having looked at the map, but you know that there's a chance of some ground being marshy and slow to walk through, and other parts being impassible. So, as you progress, your plan is subject to change. You frequently inspect the progress that you've made, and the path ahead and make alterations to your plan based on what you learn. You may choose to lengthen the route to pass by some particular scenery if you are ahead of your plan, or shorten it if you are behind.

You continue to monitor progress towards the camp. If you realise that you might not make it before it gets dark, you need to consider changing to take you to another campsite, or maybe even returning back home if your reason for delay is injury, or stormy weather. If you do decide to head for another campsite, you may choose one that is in a completely different direction from where you were initially headed, based on what you've learnt and how things have changed.


The lesson here is that the goal is what you are committing to (the camp site) but the Sprint Backlog (means of getting there) is subject to change as a result of frequent inspection & adaption.

One team, one initiative

I blogged in April last year about the importance of teams being a ‘cohesive unit’ rather than just a collection of individuals. This post expands on that concept.

Imagine an athletics club with 20-30 members. Those members agree to a football (soccer) match with another athletics club, so they begin working on their football skills, as well as all of the supporting attributes; not everybody will be on the pitch at the same time, so the rest agree to help with things like strategy and tactics, or to be ready to be substituted in when others get tired or injured.

The athletics club in this scenario is a single team, working towards a single goal (‘to beat the other team at football’).

A few weeks later, the club starts playing basketball as well, and they arrange a basketball match with a rival club on the same day as another football match with a different rival club. They have enough people to participate in both, though they will have fewer supporting people and substitutes available.

How should the team respond to having two separate initiatives?

It seems logical that the teams for each sport are decided early on, so that they can each work on practicing their chosen sport, and start working on things like set-pieces and deciding their tactics and strategy for their respective games.

The teams will likely continue to work together at a higher level — they may still be able to help each other in certain areas, or there may be training facilities (like gym halls) that they need to share and co-ordinate their use of.

If this same problem were in software, I know from experience that most organisations would tackle it in a very different way.

If this were in software, the team would continue to operate as one, even when it is anticipated that they will work on separate initiatives for quite some time. They will plan together in a single Sprint Planning session, and synchronise process and adapt plans at the same Daily Scrums.

In so many cases, this simply doesn’t make sense. To have a single team try to achieve two completely separate goals is a flawed approach, because the concept of this being a ‘team’ just doesn’t apply.

A single team can work on different features, but it only makes sense if there is a single goal. For example, a team could work on ‘registration’ and ‘login’ with a common goal of ‘authenticating users’. Even ‘registration’, ‘login’ and a ’shopping cart’ could contribute towards a single goal of ‘allowing signed-in users to purchase products’.

But, when the initiatives cannot be grouped together to solve a common purpose, or ‘user journey’, then it seems unlikely that the work to do them is going to be connected enough to warrant a single team working on it.

When a team is working on multiple goals, they need to ask themselves very honestly if they are still truly a single team, or whether they could be more productive if they were to wholeheartedly embrace the separate initiatives.

There are of course challenges associated with splitting teams, many of which are worthy of blog posts in their own right. There is no guarantee that even a healthy team will survive significant changes to its structure, and even at best a short-term dip in performance should be anticipated.

But greater issues are likely to be faced by smaller teams — it would probably be foolish to split a team of five people leaving “teams” of just two and three.

Final thought: Splitting teams should not be seen as an alternative to effective planning practices or effective Sprint Goals.