11

How do you best define a sprint goal, when the sprint's stories range across a wide number of different products?

Background: our scrum team's sprint contains stories that belong to a number of our company products and or clients. We build online stores for clients and build reusable internal products for implementation over multiple clients. We also maintain internal development tools. In a sprint we could have:

  • Story: Extend the company's reusable shipping module to handle carrier tracking codes.
  • Story: Build a widget for client x that shows the newest products.
  • Story: Write a functional design for client y's new ERP product importer.
  • Story: Add code format checking to our internal continuous integration server.

On average we have around 10 stories per sprint. Sprint goals currently are either:

  1. Very broad and non-specific to encompass all stories, which makes it useless as a guideline during the sprint.
  2. Very long, pretty much having each story included, which doesn't make it a concise goal to work towards.

At first this wasn't really a problem for our team. We'd just pick a general goal and judge progress / decisions during the sprint based on a stories acceptance criteria and definition of done. The scrum guide describes several situations in which it advises to use the sprint goal to judge whether the team is moving in the right direction. As the team's getting better at scrum the need for a valuable sprint goal is becoming more apparent to us. We're getting more in the habit of checking 'what's our overall goal', and a good sprint goal would definitely help.

Improve this question
2
  • 1
    +1. However, I don't want to be cruel. But it seems like you're asking "How do I change my sprint goal to reflect the fact I have not clear sprint goal". Something is missing from the root cause analysis here.
    – Nathan Cooper
    Aug 28, 2015 at 13:19
  • 1
    I get your point and agree. However, lots of teams have varied workloads over several products in one sprint in a probably imperfect setup. We're not the only one in the world (I hope ;) ). My questions is mainly 'how do other teams handle this'. The answers given seem to reflect that setting a concise goal for this kind of sprint is not possible.
    – upstream
    Sep 15, 2015 at 9:32

4 Answers 4

Reset to default
5

To answer your question well, it's important to first address why teams have sprint goals. The purpose of the sprint goal is to focus effort on outcome (the new or improved capability being developed) over output (stories getting done). The product owner should have a sprint goal in mind when they go into sprint planning (which of course may be adjusted during planning).

Now to address your question specifically, there are a few things to keep in mind that are perfectly:

  1. Sometimes the product owner wants to focus on a few smaller capabilities instead of one big one. This will usually result in a few smaller goals and that's not a problem. I would disagree to some other responses about different parts of the team being assigned different goals. The whole team is still responsible for all goals and they should decide internally how to do the work.
  2. Not every story needs to be covered by the sprint goal. This is incredibly common even when the team has one concise goal but has a little more capacity so they bring in the next story in the backlog. They don't need to expand the goal or make another goal to account for it (though they can if it feels helpful).
  3. If your stories are focused on output instead of outcome, grouping them together and creating goals will be much harder.
Improve this answer
1
  • Very good mentioning the product owner. Currently the entire team decides on the goal. Making the PO have a bigger role in this makes a lot of sense. I'll involve the PO more in determining the goal, so a more focused sprint will be to his advantage. Overall I think your answer contains the most complete overview of angles to look at this issue. Thanks!
    – upstream
    Sep 15, 2015 at 9:38
2

Assuming that different parts of the team will each work on only some of the projects, how about simply defining numerous sub-goals and assigning them individually to those parts of he overall team. The sprint goal would then be to have each part of the team reach their own goal.

Another option would be to break down your setup so that a sprint cannot become that diverse. But if you have so many different topics in any one sprint, I don't see how you can boil it down to a two-liner that still reflects all the diversity and complexity to anyone who wants to be able to check their progress against it.

Improve this answer
1
  • Good suggestions. We already define subgoals and I think your making a good point in that we can shift focus to those goals, instead of an overall goal. Boiling it down is indeed near impossible, so i'm very much looking for other ways to handle this situation. Thanks!
    – upstream
    Sep 15, 2015 at 9:08
2

Don't bother finding the right goal from the stories you picked. It's a symptom, not a problem.

It works the other way around: the sprint goal is not an end itself, it's a story picking tool. The sprint goal informs story selection.

Why is this a helpful thing? Here's some reading material. TLDR: If you have a clear sprint goal, it's probably also clear what value you're delivering. If everyone knows what value you're delivering, you're more likely to end up working on the right stuff.

It sounds like you aren't doing this. It sounds like your work is fairly unconnected, and the focus is on filling the sprint rather than on any specific goal (this is actually very common). Don't paper over this, the sprint goal is working perfectly, in that it has alerted you to something in your process that can be improved. Write something down, like "there doesn't seem to be a sprint goal, and talk about it during your retrospective (with your PO especially).

Improve this answer
3
  • The sprint is indeed not focused around a single goal or product, which is the root cause. Having focus on a single product each sprint would be great, but for now is unrealistic. We're working on it though. In the mean time, scrum is luckily able to handle less than ideal situations. As for 'cramming the highest quantity of work', that's not the case. It's not about quantity, in that case my question probably would've revolved around not succesfully finishing sprints. Stories are picked on their relation to other teams, projects and mostly priority.
    – upstream
    Sep 15, 2015 at 9:16
  • Nathan - the latest version of the Scrum Guide actually states the opposite of what you have said. The team pick the stories and THEN form the Sprint Goal. I personally do not coach that but it is indeed what the Scrum Guide says making most of these answers, including yours, deprecated.
    – Venture2099
    Apr 20, 2017 at 20:05
  • @Venture2009 Maybe. "It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting.... The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.". I'm not so sure that it's as cut and dry as that, stories still have to cohese, but I do accept that I seem to be working off an expanded and a little bit more opinionated version of the SG than is in the guide.
    – Nathan Cooper
    Apr 20, 2017 at 20:11
1

You may want to consider changing the way you bring work in to sprints. Is it possible to prioritise the work so that the team focuses on one product at a time?

This brings a number of benefits:

  • A clear sprint goal
  • A single Product Owner to deal with on each sprint
  • Less task switching overhead for the team (switching between products costs time)

Of course this may not be practical in your organisation. But it is worth considering as it does come with productivity gains.

Improve this answer
2
  • Whenever possible, we try to do this. The current role of the team makes this very difficult. As said, the team does a lot of varied work for multiple products. For now this is unavoidable, but we're working on improving focus in the long run. Thanks!
    – upstream
    Sep 15, 2015 at 9:04
  • One possibility would be to have a shorter sprint. That might make it easier to have it focused on one product.
    – Barnaby Golden
    Sep 15, 2015 at 17:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.