Sprint Goal - how to define?

Presumably the Product Owner values the aggregate contribution of the 4 items, and would like to receive an increment with this functionality.

Since each one of the items provides a user experience, we may infer the existence of a valid workflow, storyboard, or user journey that encompasses them all. The PO should wish to see this demonstrated no later than the Sprint Review because it would evidence useful aggregated functionality. For example, it might be a user receiving product suggestions, adding these items, submitting a payment, and then reviewing invoices.

Those are all separate PBI's, but they can be drawn together into a storyboard that represents a potentially valid user journey through the system. That journey is a single coherence and as such it could be a potential Sprint Goal.

The sprint goal could be "create a self-service transactional solution which allows customers to browse and buy products, provide recommendations and adminster/manage their own accounts"

I would like to upvote this topic that was sadly abandoned by OP.

I'm facing the same problems here, we're working on one topic but at first sight it is challenging us to "bracket" 4 or 6 PBIs into one consolidated Sprint Goal.

The user scenario approach than Ian depicts is interesting.
The attempt here above sounds to me like a cumbersome way of putting all these 4 PBIs in one sentence. Having one sentence doesn't make it a goal.

If I look at this article for instance, the first example just doesn't sound like what a Sprint Goal is meant for

Sprint Goal: Complete Five User Stories and Fix All Production Bugs

This is just a statistical and purposeless description of the sprint.

http://www.luxoft.com/blog/vmoskalenko/7-sprint-goal-patterns-for-build…

Have a look at this article I wrote last year on "Sprint Goals in Practice":

http://dzone.com/articles/sprint-goals-in-practice

Thank you guys for the ideas. I really appreciate your help.

Hi All,

I face a similar issue every sprint. To give you all a background, we have 4 small tools/applications against which we have 1 PO, 1 SM (me) and a dev team (3 developers + 1 tester). We do a 2-week sprint that has a max of 10 working days or less depending on any public or company holiday during that time. We pick up stories considering the no. of days and resources available.

In our backlog refinement sessions, we groom the prioritized stories and estimate them too. In the sprint planning meeting, I don't define the sprint goal since I am not aware of what that can be so I skip it and pick the top stories depending on the capacity planning shared by the dev team and formulate the sprint backlog. This is in consensus with everyone in the team. 

But I don't define sprint goal. It ain't impacting anything but I know I am skipping a process. Can someone please guide me how to define the goal and where to mention it.

Thanks

In my team we use JIRA to manage backlogs, and for a sprint backlog we are able to set a big, visible header / title that contains a sprint goal. A good think with a sprint goal is that allows you some space to move around obstacles you might encounter while working on stories from the sprint backlog. Suppose one of the stories was hugely underestimated, and you know you cannot deliver everything that was forecasted - in this scenario, having sprint goal in mind, you sit down with the PO and decide what has to be kept to still deliver the sprint goal, and what needs to go.

We always try to pick something that is meaningful for the team as a sprint goal, but it does not have to be 100% of the sprint backlog. For example, a sprint goal can be to implement feature A, while other tasks will be about fixing bug B and doing less important feature C...

Aarti,

Is the work that the team forecasts each sprint somehow tied together under a common theme/benefit, or is the work a list of high-priority but loosely or non-connected items?

You will struggle with formulating a Sprint Goal (or reaping the full benefit of Scrum) if the majority of the items each sprint do not fall under a larger initiative.   Kanban, or Scrumban, or Scrum with Kanban, may be alternatives then to Scrum.

Thanks all for reverting.

In total, we have a scrum team in India that take cares of 4 small tools/application. Collectively they form a big project but individually we could not have had a dedicated scrum team for each. 

We usually try not to pick up stories that are from all the 4 systems in one single sprint. We target either 1 system or max 2. It all depends on how the business prioritizes the stories. Sometimes, we have picked up stories from all 4 tools, where few minor (1 or 2 pointers) stories are picked up from few systems however the major functionality goes in the rest of the 2 tools. 

Is that ok if my sprint goal doesn't talk about the features that are estimated at 1 or 2? And we can only use the important feature as sprint goal. If that's the case, then what if there is an issue in delivering the low pointer stories.

Thanks

I think the situation of selecting divergent PBIs in a sprint is not a sprint planning issue, but a backlog management fault. Product backlog should be prioritized based on a road-map that is broke to short-time milestones and sprint goals are mapped to those short-time milestones.

By this definition almost all PBIs selected for a sprint inherently have connection with each other.

In a previous team, we had not been setting Sprint Goals.

When we eventually tried, we found it uncomfortable. Our goals seldom felt useful, weren't something we would pay attention to, and took a lot of energy from the team, as we wrestled with various sentence constructions, and had existential arguments about the point of our Sprints.

The most obvious conclusion was that Sprint Goals were a waste of time; but eventually they helped us realize that our main problem was a lack of focus. We were task oriented, and weren't able to look at what we were doing as part of a broader purpose.

Push yourself to set good Sprint Goals – especially if it hurts.

Hi:) 

Sprint goal seems to be as much difficult as important thing in scrum process. 

In reality if we have no a goal for sprint so what do we want to achieve at the end of sprint time.

I totally agree with Esmaeil Vakili. PO is responsible for product backlog, sprint backlog and he or she has to define a sprint goal in appropriate way.

Sprint goal is this thing which is in my opinion most important thing for the scrum team and creates a sense of its being. There is no more important thing for a team than one common goal and cooperate focusing on it. 

Push yourself to set good Sprint Goals – especially if it hurts.

Good one Simon. We also have a hard time with Sprint Goal Definition, due to most of the factors mentioned above. As you mention, this is most likely a symptom of a much larger problem.

I totally agree with Esmaeil Vakili. PO is responsible for product backlog, sprint backlog and he or she has to define a sprint goal in appropriate way.

I beg to differ:

• The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.
• 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

If you're a Scrum Master don't wait until the last 15 minutes of Sprint Planning and expect the entire team (PO & DT) to define a meaningful and believable sprint goal.

Instead, during the Product Backlog Refinement or Product Backlog Grooming session(s) ask the entire team to start thinking about what the Sprint Goal might look like based on the PBIs being reviewed. 

Prior to Sprint Planning, set aside the time for a brainstorming session with the PO in order to define his/her Sprint Goal.

In most cases the PO's Sprint Goal is a reflection of the his/her vision which when presented to the DT, during Sprint Planning, serves not only as a conversation catalyst when the time comes for the DT to define their Sprint Goal, but also conveys to the individual DT members the value and meaning behind the work they are committing to. 

Good approaches Michael.

I also follow the PO "vision" angle in helping my teams craft meaningful Sprint Goals.   A common strategy I use is to have them pretend that they're on an elevator when the CEO walks in and asks what they're working on.   Can they capture an "Elevator Pitch" statement that captures why they're even executing a sprint?   

I also coach them to focus on business value being targeted, and away from the "how" of what they intend to do.   Starting Sprint Goal statements with value-based action verbs like "Improve", "Enhance", "Eliminate", "Provide", etc. helps greatly.

Unlike Michael and Timothy, my practice is to delay the discussions or the draft sprint goal(s) (if two or more are on the table) until the most relevant catch up (review) happens.

In my opinion, while there is, surely, significant value is being proactive, I'd say product backlog refinement has different goals, and rather than thinking about what the next sprint goal might be, I'd like the team to be focused on actually refinining the backlog - discussing, understanding, asking and questioning, cooperating, defending or contending opinions, and ultimately estimating.

The review (or right after it), to me, is the best place to discuss about how the next sprint goal might look like, and being right before the sprint planning, the information is fresh, reliable and with no waste incurred. Then it's up to the DT to see what's achievable.

It seems that all of my teams do it slightly different than the others.

One will craft the goal at the beginning of Planning based on their knowledge of the targeted increment for release and their past refinement sessions. This helps the team focus on getting a set of stories that will deliver a working increment that takes them towards the "release" increment. 

Another crafts the goal at the end of Planning just before starting the Sprint. They say it gives one last chance to ensure that they are all on the same page. If there is confusion/disagreement on the goal, they will discuss and have actually redone the Sprint Backlog.

A third crafts their goal at various times during the Review/Retrospective/Planning cycle based on their gut feel for when it makes most sense for them.  

Are any of these wrong? I say no because it works for that team. 

I like all of the discussion that has occurred on this thread over the past 4 years. It has given me some insights that I can use when a team is forming or is having trouble with Sprint Goals.  Thanks to all.

@Eugene,

Just to clarify, my teams craft their Sprint Goals during Sprint Planning.   They are not discussed beforehand (i.e.c - refinement).   

However, I do work with the PO during each sprint to help them identify and prioritize future work, and to begin thinking about their "vision" for upcoming sprints.

I definitely misunderstood you, Timothy! Thanks for clarifying :)

Here I great Article about the Sprint Goal

https://medium.com/@daviddenham07/the-sprint-goal-the-scrum-time-paradox-d6e69c5947fa

For me the best statements in the article are:

- When teams best apply them (Sprint Goal), they can really help them focus, have a sense of purpose, and connect back to higher strategic goals.

- In more recent versions of the Scrum Guide, this was updated to have a draft version of the Sprint Goal introduced before pulling in PBIs. We are starting with a goal, based off a higher level release or strategic goal (hopefully!), and then selecting the outputs needed to make progress against that.

It may seem like a tiny change, but the order of goal setting vs output creation can influence how we view a goal and how we view scope.

- We can still achieve the goal, but with different scope than originally planned.

- The sprint is a container for innovation -> the timebox of a sprint can be a great forcing function to think creatively about how to achieve more outcome with less output than originally planned.

When viewed like this, this makes a sprint a fixed time, variable scope container, with the sprint goal front and centre as the outcome we’re trying to achieve as a team.

- Roman Pichler’s Sprint Goal template

Sprint Goals are great for allowing your teams the empowerment of making decisions and being held accountable for them during the Sprint.

When/if Scope Change is treated negatively, it may create an anti-pattern that can ultimately bring forth ScrumFall, where teams put together scopes of work for a sprint and they work on them diligently. This may sound great, until they learn something.

That learning may cause planned work to no longer be needed or as high a priority. It may also require new work to be brought into the sprint sooner than later. These changes can appear as bad performance from a metrics perspective, but staying on course (following a plan) is the worse action.

• Ex: Sprint Goal = Customers no longer have to use WorkaroundA to utilize ExistingFeatureB
  • Sprint contains Stories 1 through 4 in order to achieve that Goal
    
     
  • Team finishes Story1 and learns Story2 and Story3 are no longer required because Customers saw Story1 and changed their mind.
    • Story2 becomes Canceled while Story3 will be needed at a later Sprint.
      
       
  • To best support Story4, we need to first bring in and complete Story5.

How much Scope Change was encountered? None. The Sprint scope has not changed or become invalid. What would the benefits be at capturing scope change at the story level? Would it bring the team closer to predictably delivering desired outcomes?

John, while I agree with much of your post, I'm not sure that I agree with your conclusion that there was no scope change in your scenario.

Certainly, the Development Team must be allowed to alter their Sprint Backlog as needed in order to meet the Sprint Goal.   But while the team leverages the Daily Scrum as an inspect and adapt event to adjust their Sprint Backlog, their changes can indeed result in overall sprint scope changes that may either require item(s) to be de-scoped to accommodate additional scope, or create capacity to allow additional item(s) to be brought in.

Also, I would argue that it is important for the Development Team to assess scope/size at the story level, in order to evaluate sprint progress, assess the likelihood of meeting the Sprint Goal, and support predictability.

That's a fair point Timothy. The reason I said there was no scope change at the sprint level was because the sprint direction did not change, under the assumption that this was the only sprint goal.

I should've clarified I was only using one sprint goal in that example sprint.You are correct that there would potentially still be scope change at the sprint level if there were additional sprint goals and one/some are affected by the decision to this particular sprint goal. 

Looking at this example of having just one sprint goal, if after the learning the team determined that WorkaroundA needed to be modified further instead of being able to allow customers to no longer require needing it, I would certainly call that scope change to this sprint goal because now the direction of the sprint has shifted.

If you were also tracking scope change at the story level, I would be interested to know why and what benefits you gain? I feel like it would only lead to enforcing behaviors that encourage following a plan over responding to change.

John, I'm not sure we're operating from the same understanding.

I do not view sprint scope as something directly tied (1 to 1) to a Sprint Goal.   I view scope in terms of forecast - the Development Team believes they can complete this list of items in the upcoming sprint, and some/all of those items support the Sprint Goal.

As the sprint is executed, the Development Team may add/remove items from their Sprint Backlog as they see fit, as long as the Sprint Goal remains viable.   In my opinion, this addition/subtraction of items can equate to a scope change, if the result is a Sprint Backlog of greater or lesser complexity or effort.

My argument has nothing to do with the number of Sprint Goals.   Unsure why multiple Sprint Goals is even a discussion point, if we're still talking about one Development team.

Loving the dialog Timothy! I think the strategy comes down to how each team uses their Sprint Goal.

I currently operate with two teams which service a different product each.

• TeamA owns ProductA and TeamB owns ProductB
• Each product has at least 2 main features in flight, each feature servicing a different group of stakeholders.
• We use a Sprint Goal for each feature.
  • In that light, we do tie 1 to 1 sprint scope to a Sprint Goal.
  • That helps the PO and Team maintain prioritization and ease of Sprint Planning, as well as create realistic deliverable timelines.
• We reserve a % of capacity for maintenance type work each sprint, like 70/30 for example Sprint Goal to Maintenance work, where Maintenance is treated like Stretch Goals.

So our forecast isn't about a list of items being complete, but rather the forecast of the state of the features by sprint end. We measure how successful we are at delivering to expectations of functionality as opposed to how many stories we complete (outcome over output or success over performance).

The team doesn't shy away from delivering the Sprint Goals. Sometimes they make choices based on feedback of completed stories within the Sprint.

• If the feedback alters a planned story, we re-refine the story before it begins work (shown as story level scope change).
• Sometimes we bring in other stories but we won't trade out stories just because something was added.
  • If the added story changes the expectation of the Sprint Goal, capture it as sprint level scope change, otherwise it's not counted (goal is unchanged).
  • If the added story replaces an in-sprint story, then we just close that story as Canceled, and again if the Sprint Goal is unchanged, then no sprint level scope change.

This allows the team to make decisions and be held accountable for them, while freeing them from micromanaging good/bad decisions that affect the burndown. Adds to their sense of accomplishment and ownership and builds trust to stakeholders that the team is making decisions to best meet their expectations and needs.

John, I agree with focusing always on the Sprint Goal first, and secondarily the items in the Sprint Backlog.   I do have some concern with other aspects of your approach, though.

You state that for each product, a number of "features" are actively being worked on, and each feature is supported by a separate group of stakeholders.   According to you, a team may have multiple "goals" per sprint to represent sprint-based objectives for each feature.

Below are just a few of the issues I see with this approach:   

• There is a reason Scrum only allows a single Sprint Goal (Focus).   Allowing multiple "goals" is simply not Scrum
• By asking the Development Team to target two or more "goals" in a sprint, you are risking the team dividing along those lines and working separately, which can reduce the value and effectiveness of the Daily Scrum, and reduce overall communication and collaboration within the Development Team
• More than one "goal" increases the likelihood of context-switching, which can significantly reduce the capacity of the team 
• Having more than one "goal" creates confusion and unneeded complexity around the success of a sprint.   Was it successful if only 2 of the 3 "goals" were met?

As a Scrum Master, this seems to be a perfect opportunity to educate the PO and stakeholders about the benefits of focusing sprints on a single feature at a time.   It is a proven fact that one will complete items A, B, and C in a shorter time if they are done in sequence, than if one attempts to make progress on each of them simultaneously.

My suggestion is to have your Scrum Team experiment with focusing on a single Sprint Goal for several sprints, and assess their experience and whether they delivered more functionality than they would have under the old approach.

What you said makes great sense. Perhaps this is not Scrum. Or perhaps we need to be ok with generalizing the Sprint Goal a bit more. I hope you don't mind me painting a picture in full detail and you offering some more input?

Often times the way the Sprint scope looks is a mixture of:

• Work to wrap up a feature
• Research to prepare for the next feature OR start the next feature
• Enhancements to existing features

Scrum as a framework is process agnostic. With our process established, we need to create a Sprint Goal to set the guardrails of the Sprint which will allow our process to successfully create the Increment and sustain an appropriate pace for the team.

The true challenge we face is making the Goal represent the Sprint Increment AND have it be meaningful to the team. I think this is the part where we may diverge from Scrum.

The team came up with the idea of using multiple Sprint Goals because writing a single goal needed to be too widespread, and working in one-week Sprints would be too much overhead. Finishing the Sprint 'felt' successful but wasn't easily proven to be so (culture issue?). Retro's would end up focusing on optimizing the processes as a result.

I too warned of context switching. They still prefer to only work on one set of stories at a time, so the team actively sequences their Goals by priority provided by the PO. However, they believed that since they own their product and it's all one codebase, no major concerns exists since they talk through their execution plan together as a team well in advance. 

So...how to enable the team to show their level of predictability (their level of success)? We defined it as ability to meet or exceed expectations of functionality. Not nearly as important to pick a day and hit a day, as it was to believe something is done and have it not be so.

Team then used that definition to set expectations on groups of stories aligned towards common value and functionality and ended with multiple Sprint Goals:

• Goals:
  • Issue preventing users from viewing X data is resolved in Production
    • Assume 2 stories required to accomplish this
  • CustomerGroupA is able to perform Y and view the results on pageA 
    • Assume 3 stories were required to accomplish this
  • CustomerGroupB is provided an endpoint that will give them DataZ on demand.
    • Assume 1 story is required to accomplish this
• Stretch:
  • NewFeatureB request is understood and PoC/Research is ready to be presented to the team
  • BugFix1 is delivered to Production and IssueDelta is no longer a problem for CustomerGroupC

We deploy multiple times throughout a Sprint, as soon as a completed Goal is accepted. If something needs to change, the change is compared to the Sprint Goal. If we can't call the Goal done, we add it to the Sprint and work on it first. Often times though the team gets continuation requests on the feature set, which ends up as work for a future Sprint.

At Sprint Review we can demo the system as a whole to any/all stakeholders.

As far as evaluating how successful a Sprint was, we're trying out a % Successful metric.

• Planned = 2 points per Goal (not including Stretch) 
• Actual = 2 points per completed Planned Goal + 1 point per completed Planned Stretch + 0.5 points per completed Goal added/changed in the Sprint
  
   
• Actual / Planned = % Successful (completed Goal = accepted and deployed)

What are your thoughts on our process? Is it still Scrum? We used the Sprint Goals as guardrails for the Sprint, set the expectations for the Increment, and accommodated for sustainable pace. Team worked sequentially throughout. The rest of the framework events remained intact.

Hi,

based on the general topic, I try to conclude following guidelines or even rules to myself:

1. a sprint goal can be made of 2-3 PBIs OR

2. a sprint goal can be exactly 1 PBI.

Is that correct because it depends on the PBI type (epic or story) and/or the project?

Sometimes I see teams define Sprint Goal(s) as a list of bullet points (in this case, there are multiple goals). Is that correct or should the Sprint Goal be one item (generally one sentence)?

Sometimes I see teams define Sprint Goal(s) as a list of bullet points (in this case, there are multiple goals). Is that correct or should the Sprint Goal be one item (generally one sentence)?

The Scrum Guide says "The Sprint Goal is the single objective for the Sprint". If there are multiple goals as you say, wouldn't you then have evidence that the necessary single objective is lacking?

Exactly that leads to a lot of issues in crafting the one sprint goal. If a number of PBIs contains the biggest value for the customer but they are single goals, crafting the one and only sprint goal over these values might result in a strange exercise.

But if you are at that point, then you already wrong. Have a look on Roman Pichlers Sprint Template, it helps a lot to craft the goal.