Useless sprint goals

chaos-soccer-gear-Cjfl8r_eYxY-unsplash

A sprint goal helps to enable the team to focus on for the next 2 weeks. What does everyone want the team to work on next?

The Scrum Guide [Oct 2011] states:

The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. As the Development Team works, it keeps this goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the Development Team expected, then they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint. The Sprint Goal may be a milestone in the larger purpose of the product roadmap.

A sprint goal will be met through the implementation of the appropriate product backlog items. Working with the product owner, stakeholders, customers and users, the team identifies the product backlog items it believes it can develop during the next sprint to meet this goal. However, like many things in agile a key concept is ‘negotiation’. A reason for having the sprint goal is to give the team some leeway regarding the functionality and technology it delivers. During the iteration, the team determines daily how to meet the sprint goal. If the work turns out to be harder than expected, the team might only partially implement the functionality. At the sprint review meeting, the opportunity is given for the product owner and stakeholders to review how and what was implemented – they review how the sprint goal has been met. If they are dissatisfied, they can make decisions about the product backlog, architecture, team composition or release plan.

For short iterations (e.g. two weeks), the sprint goal may not always add a lot of value. With a two week iteration the team’s work may be sufficiently described that their goal becomes “complete the backlog items we selected.” For some teams I’ve observed a sprint goal may be useful but usually having better thought-through product backlog items works better. For these teams having release goals may make more sense than sprint goals. The teams that benefit most from sprint goals are those who have longer iterations (e.g. four weeks) or have just a few large product backlog items, as the goal provides some guidance as what we want to achieve and focus on.

Here’s an iteration goal for a team:

“Finish the agreed forms, portlets and web pages for News and Media then pick up additional stories to increase the team’s velocity”

Whilst this goal is ok, it gives no room to negotiate – it’s a very ‘command-and-control’ type statement rather than a goal to work towards. A small tweak by removing ‘agreed’ would provide some room for negotiation – “Develop the forms, portlets and web pages for News and Media site”. In addition, the second part of the iteration goal, “[…] then pick up additional stories to increase the team’s velocity” may be better suited belonging in the team’s social contract rather than in the sprint goal. ‘Doing more story points’ is an indirect result from focusing on WIP limits, pull, removing blockers, being a collaborative team and continuous improvement.

I have seen some sprint goals simply stated as “Complete x story points”. This is a useless goal as it provides no focus on what to work on other than to do achieve a number of story points (which leads to other issues such as story point inflation). So what if we have delivered ‘x story points’ if we didn’t deliver what the customer wants or delivered no business value.

So the idea behind a sprint goal is for the team’s output to be evaluated against the goal rather than the specific product backlog items they selected (there is a subtle difference). In a way it gives the team the opportunity to say “Well we didn’t finish all the backlog items but we met the goal.” Instead of having a sprint where we just ‘do more stuff’ the sprint goal can provide a theme the team can work towards. A sprint goal could be: