Craft a sprint goal when objective requires multiple sprints

The team I'm part of is struggling finding the next product goal

Let's put the matter of goals to one side for the moment. How does the Product Owner intend to account for value, to stakeholders, during each of the Sprints you mention? How will value be empirically evidenced?

Bear in mind that value could lie in the reduction of migration risk.

A Scrum Master helps the team with techniques to improve their ways of working (sometimes).

"The list of interconnected feature has value only when all the features have been completed." - I've seen this too, and often the result of lazy planning. Vertical slicing and considering the smallest possible increments are positive patterns to use.

When people say 'it's only valuable when we've got everything', I often find they mean 'it will only be ready to demonstate the full functionality, and be released, once we've got the full end to end'...that doesn't mean we can't get feedback.

Scrum is about Done work, and whilst releasing frequently to validate value is encouraged, it's not mandated. Getting feedback, at the very least in every Sprint Review, is a key part of an empirical framework.

The value of each sprint that the PO has in mind (and the one she wants to communicate to the stakeholder) is that, at the end of the sprint, we'll be a step closer to a working prototype of our product with the new technology.

The stakeholders see the value of this refactoring (better performances, better maintainability) and everyone is working towards the objective of creating a testable prototype which indeed will reduce the migration risk. However, this objective can't be achieved in one single sprint. We have several stories, splitted so that the team can complete them, but the value of which is in the sum of the parts which have to be divided in multiple sprints.

The problem I'm encountering is finding a good way to motivate the team with a goal to focus on. The "getting a step closer to a working prototype" may be a good goal once, but it would repeat and repeat and repeat until the last brick on the wall has been completed and the prototype released internally.

Try defining what each of those "steps" are and crafting Sprint Goals and Backlogs to support reaching each step.  That provides value and supports the ultimate Product Goal.  You said that the items were broken down so that Developers can work on them in a sprint duration.  Start grouping those items together in a way that create single definitive plateaus (i.e. steps).  It would be even better if each of those steps represents something that the stakeholders could review and provide feedback. 

Scrum focuses on delivering increments of value that are reviewable by stakeholders.  If you are not doing that, then you are not really using the Scrum framework.  You are just doing a waterfall project with stages built in. 

I've seen someone translate goals into 'starwars'. 



'blow up the death star ' is a 'cool' goal to aim but you can't put it out on sprint 1. Take your long-term goal as a release goal, but split up your sprint like stepping stone in the movie.  



- receive help message from R2D2  (aka, complete the web service so it can answers our calls )

- learn to be a jedi  ( aka, shadows prod fonctions so we are ready to replace the web service )

- watch Ben Kenobi die ( remove old web service from prod ) 

- fight vs darth vader ( QA / test case / regression test )

- blow up the dead star ( implement new front end ; aka release #1 )

 

 etc ... build up other goals base on star wars movie will be easier than : "advance the developpement of prototype for sprint 10" and the dev will see the underlying story plan out and the hidden goal of 'blowing up the death star" comming up. 



------------------------



of course, ideally, knowing have many sprints you have remaining to meet the deadline ahead of time might help to build up good goals vs the job that needs to be done.



I found the star wars image easier to grasp when I was struggling to find good goals myself.

- receive help message from R2D2  (aka, complete the web service so it can answers our calls )

- learn to be a jedi  ( aka, shadows prod fonctions so we are ready to replace the web service )

- watch Ben Kenobi die ( remove old web service from prod ) 

- fight vs darth vader ( QA / test case / regression test )

- blow up the dead star ( implement new front end ; aka release #1 )

I disagree with this approach. This sounds like testing will only take place during the 4th sprint, which makes me wonder how on earth (or Endor), the earlier sprints could have resulted in a done increment.

Instead it seems likely that it's accepted to hide risk in the earlier sprints, and only let that emerge somewhat down the line in a waterfall way.

Also removing an old web service as a goal is unlikely to provide a transparent increment in itself, as outwardly the removal of that service should not be noticeable.

In the film, I'd say this is akin to Luke progressing to a level of excellence, at which point there was no longer a dependency on Ben Kenobi. Luke's maturity and ability as a Jedi could be inspected. Seeing Ben Kenobi die was not a goal in itself.

It's long long ago since I watched Star Wars, so I can't remember all of the details, but perhaps an alternative way of looking at it might be:

• Luke reacts to call for help
  
  A web service is built to send the message, but it currently only needs to work in a very thin way, there is also a very thin amount of infrastructure, UI and automated testing to ensure the functionality works and will continue to do so, as long as it's needed.
  
  It might have been enough to have a goal to simply send the message., but I've chosen an outcome focused goal.
  
  By trying to get Luke to react, there's something very valuable to inspect. Is Luke actually helping us? If not, why not? Imagine Luke didn't understand the urgency or he was a jerk and decided not to help.
  
  This would be great input to have before Sprint 2, as then the rebel alliance could reconsider its plan.
• Luke uses the force for the first time.
  
  Dependencies on older services like Ben Kenobi are gradually being removed. Luke's proficiency with the force can be inspected.
  
  QA is done throughout. At no point is Luke encouraged to develop in a way that risks defects.
• Luke can fight with a light sabre
  
  This is an incremental improvement of Luke's ability with the force
• Luke can fight that floating ball in the air with his light sabre
  
  This is another incremental improvement. Further goals can be set for inspecting this improvement.
  
  At some point, the dependency on Ben Kenobi is no longer there, and so he can die (old services can be removed), allowing Luke to still function.
  
  The removal doesn't take long, and there's minimal downtime for Luke, because of the way he had been carefully developed prior to that.
  
  Further incremental improvements can be planned, as needed.
• Defeat Darth Vader
  
  The goal wasn't the fight itself. The goal was to defeat him.
  
  Ultimately this didn't happen.
  
  Some Sprint Goals aren't achieved, but at least there is something to inspect.
  
  Unfortunately for Luke, this is the need for a prosthetic hand, and some troubling news about his father.
• Luke is able to use a prosthetic hand
  
  This is a change in direction. The previous sprint didn't go to plan, and new work also emerged. Setbacks happen, but it's important to make this improvement now, to remain on target towards the Product Goal of blowing up the Death Star
• etc.