Sprint Goal - Every Sprint?

During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

That is copied from the Scrum Guide section on Sprint Planning.  Since each Sprint Planning event is to plan a single sprint and a Sprint Goal is crafted in each Sprint Planning event, I believe that the Sprint Goal is per sprint.  If you go to the Sprint Guide and search for "sprint goal", while reading the text around those references you will see a pattern where the sprint goal is related to a single sprint.  There can be many levels of goals in software development.  But in Scrum, there is only 1 Sprint Goal and it has the potential to change every sprint based on the work that is being forecasted for that sprint. It is also possible for the same Sprint Goal to be adopted for multiple sprints but even when that happens it will stand alone for each sprint.  You do not accomplish a single Spring Goal in multiple sprints. You accomplish a Sprint Goal in a Sprint.

I think what you may be searching for is what some organizations call outcomes. Where I have encountered outcomes, they usually spawn one or more Epics that are used to accomplish the outcome.  They basically provide a goal for the Scrum Teams to refine into smaller units of work where each unit builds into the outcome.  

Hi

I agree with Daniel.

Sprint goal is very needed for proper work of scrum team. 

Not sure I understand what you meant here, Daniel:

It is also possible for the same Sprint Goal to be adopted for multiple sprints but even when that happens it will stand alone for each sprint.  You do not accomplish a single Spring Goal in multiple sprints. You accomplish a Sprint Goal in a Sprint.

Can you please clarify?

@Eugene

We have a couple of times where the story makeup of our Sprint was actually working towards the same goal.  For example we were moving a lot of legacy systems from internal hardware to clouds.  We ended up using the same goal on two sprints because we were moving services that supported the same end application.  The goal was to prevent the disruption to the Production Application's use while getting portions of the services it depended upon into the cloud.  We could have been much more specific with our goal but in the end it actually helped us focus on the real goal of not disrupting the production application use instead of just moving a group of services into the cloud.  In the second sprint we actually decided that one of the stories could not be completed because it would require a window of downtime.  That item was moved to the next sprint so that we could coordinate with the users for a maintenance window. 

Does it make a little more sense now?

Indeed it does, thank you!