The Sprit Goal is selected BEFORE or AFTER the Sprint Backlog is created

Hello, Can anyone help on this question ?

Thanks a lot.

Scrum Guide is quite clear about that. "After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal.". This happends when team's answering the Topic One question What can be Done in the Sprint?

I agree with you that: After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal.


My confuse is: The activity " forecasts the Product Backlog items " and "create the Sprint Backlog" are SAME or NOT ?

Can i understand that the flow as below ?
forecasts the Product Backlog items -> **create Sprint Goal ** -> **create the Sprint Backlog ** !


Thanks.

No, it's not the same. Forecast is about PBI only, "The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog." Thus Sprint Goal is created before.

In addition, as the defination of "Sprint Backlog" :
= Selected Product Backlog item + **Plan to "done" them ***

That may mean: Sprint Backlog is made at the end of the first session of Sprint Planning meeting, after done some prior activities (including make its Goal)


Can anyone help to clearify about this ?

Thanks Illya.

So final answer is "Sprint Goal is create BEFORE Sprint Backlog ?

Sprint Backlog is the output of the "How?" topic of the planning, Sprint Goal is crafted during "What?" part which comes first.

I clear, thanks so much.

> So final answer is "Sprint Goal is create BEFORE Sprint Backlog ?

Be careful when you talk about the Sprint Backlog being "created". The Sprint Backlog serves the purpose of meeting the Sprint Goal, and its ability to do so must be improved at every opportunity during the Sprint.

Well, as I remember Ken saying about that Scrint Backlog is like human - born during the Sprint Planning, emerging and evolving through the Sprint as a human being walking throughout the life.

agree!
when you have the sprint backlog created you are ready to start working for the next few days. it would be obselete at that point of time to formulate your sprint goal! goal should be set prior actions...and under that context sprint goal should be defined before your sprint backlog has been created!...

The Scrum Guide states "After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal"

I was confused by this as well when I was first learning about Scrum. I think the product owner should have an idea of what the sprint goal or objective is before sprint planning (Scrum Guide p. 9 "The Product Owner discusses the objective that the sprint should achieve..."). This aids the product owner in preselecting the PBIs to bring to the team for consideration for the sprint (in addition to their value, etc.). It also aids the team in creating the formal sprint goal at the end of the sprint planning session.

> I think the product owner should have an idea
> of what the sprint goal or objective is before
> sprint planning 

The PO should be able to enter Sprint Planning sufficiently prepared to negotiate an increment of value. This could mean having deas of what a Sprint Goal might reasonably be. It should not be an assumption or pre-condition as to what the Goal actually will be.

before

Interesting conversation. While comparing between Sprint Backlog and Sprint Goal, Indeed the Sprint Goal is decided before the Sprint Backlog. In fact, based on my experience it is decided much earlier by the Product Owner  i.e. before the "Sprint Planning" meeting by him managing the Product Backlog Items throughout the product lifecycle. 

This is how it works from my experience with Sprint Planning and as per Scrum Guide:- 

The Development Team first picks up few "top" items from the ordered list of PBI's [which is prioritised by PO and should ideally be meeting the Sprint Goal] to forecasts the functionality that it can deliver during the sprint based on its capacity and past performance.The Product Owner discusses the objective that the Sprint should achieve [based on his "top" few PBI priority list].

The entire team collaborates on the understanding and crafts the sprint goal along with a plan of action for few days to start the sprint. 

The Point is: - The Sprint Goal of what needs to be delivered in the Sprint is actually already been highlighted and managed by the PO by the list of priority items in the Product Backlog [Or Revised Product Backlog including the outcome of previous sprint review meeting if any] "before" the Sprint Planning for the Sprint starts. It's the responsibility of PO to keep this list in correct order to meet the Sprint Goal as deemed by the PO to achieve maximum benefits/ROI. 

Regards,

Rajat

The answer is BEFORE.

Thanks Rajat and Zi Wang.  That is exactly was was required. Short and to the point.

Actually, that depends a lot in what format you do the Sprint Planning meeting. In the past it was divided into two distinct sections (with 50% allotment of the total time box), but in the current Scrum Guide this has been changed and teams can now discuss "what" & "how" for each PBI one by one and then the Sprint Goal may be crafted at the end. Also, the Sprint Backlog is the forecast - at least its part containing the PBIs - so the answer is not as clear is would seem at first glance. In any case the Goal can't be crafted before it is known what items made it into the sprint. 

So can we sum up like this - 

PO presents the PBI which are ordered as per his understnding -> Dev Team forecasts what it can deliver in current sprint -> Scrum team then crafts the Sprint goal -> Dev team then prepares a plan to deliver selected items keeping Sprint Goal in mind -> Sprint Backlog is ready when such plan is ready for first few selected items -> Sprint Planning ends and Dev team starts the work and keeps updating the Sprint Backlog till end of sprint keeping Sprint Goal unchanged. 

Please let me know if my understanding is not correct.

Thanks 

Govind.

I've always had a problem with reconciling the "selection of work from the Product Backlog" with the "Sprint Goal".

E.g. only 10 points of 30 might relate to the one chosen sprint goal - Do we pat ourselves on the back if we complete the 10 points that relate to the Sprint goal and we don't complete any of the 20 points remaining. Yes, we hit the sprint goal, however we have only done one third of the velocity we expected.

Its easy to default into a Sprint goal of "X and Y and Z", which isn't great for a team, but it is a reflection of the ordered backlog.

Is a sprint successful if the Sprint goal is achieved but other high priority stories/dependencies/tasks are not?

I've always had a problem with reconciling the "selection of work from the Product Backlog" with the "Sprint Goal".

E.g. only 10 points of 30 might relate to the one chosen sprint goal - Do we pat ourselves on the back if we complete the 10 points that relate to the Sprint goal and we don't complete any of the 20 points remaining. Yes, we hit the sprint goal, however we have only done one third of the velocity we expected.

Creating a useful Done increment which meets an agreed Sprint Goal ought to be more valuable to consumers than any measure of velocity. The team may congratulate themselves on delivering that value, and also for recognizing that in order to have an achievable Goal no more than 10 points of work could be associated with it. They may decide to revise their projected velocity in future so it is more realistic, and/or investigate why the 20 points of additional planned work was unachievable.

Its easy to default into a Sprint goal of "X and Y and Z", which isn't great for a team, but it is a reflection of the ordered backlog.

That doesn't sound like a Sprint Goal at all, since it does not make the selection of work coherent.

Is a sprint successful if the Sprint goal is achieved but other high priority stories/dependencies/tasks are not?

Yes. A team plan to meet a Sprint Goal, and inspect and adapt their progress towards it accordingly. Development Team members personally commit to the goals of the team. The Sprint may even be cancelled if it seems unlikely that the Sprint Goal will be met.

It is created during the Sprint Planning meeting, please refer the page 11 of scrum guide.

The initial concept of the Sprint Goal is set during the WHAT part (1) of the Sprint Planning meeting when team tries to figure out WHAT REALLY to accomplish for the next Sprint. There are HIGH LEVEL PBIs (top ones may have been decomposed if they team is doing good refinement sessions) with no detailed tasks , dependencies, etc

As the team continues their discussion into the HOW part (2) of the Sprint Planning meeting this initial Goal is further finalized and adopted by the team as they further DECOMPOSE these PBIs and add more specifics, dependencies and order (not to be confused with the order of the PRODUCT backlog, if not timeline) of how they want to tackle the activities within the Sprint Backlog that is taking shape. (Remember this Sprint backlog has already begun when you started the WHAT discussion when you started picking items)

Please do not try to separate any activity into a standalone effort

1) The discussion of HOW will identify certain sections of WHAT that we may have overlooked or may not want to do based on what we REALIZED during the second part of the discussion

2) Thought the initial draft of WHAT (Sprint Goal) is derived in the first half of the discussion, it should be updated and can be complete only after the second part of the discussion

Please try to understand the evolution of thought during the entire meeting and why. It is not as easy as First part is Goal and second part is Sprint Backlog. First part is MORE about the goal and second part is more about HOW to accomplish that goal. The Sprint backlog starts taking shape in the first part and gets granularity and corrected (PBIs added or removed) during the second half.

Based on the 2017 Scrum Guide, I would describe it like this:

Sprint Planning opens with a collaborative/exploratory session between the Product Owner and the Development Team. The Scrum Guide is a little back to front ( pg. 11 second last para. ) as it talks about the Development team forecasting functionality to be delivered this Sprint before hearing from the Product Owner.

The Product Owner brings his/her objective for this Sprint, and the whole SCRUM team collaborates to understand the work of the Sprint.

Once understood, the Development Team selects the Product Backlog Items ( PBI ) needing to be delivered to meet the objective. ( This might confirm/augment the Product Owner's selection )

Now the Sprint Goal is agreed by the SCRUM team.

Next, in the "what" part of Sprint Planning, the Development Team craft the Sprint Backlog. This is the set of PBI and the plan to deliver them.

The Sprint backlog evolves from Sprint Planning, as more is learnt, and can change during the Sprint in agreement with the Product Owner.

To answer the original poster's question The Sprint Goal is crafted first, then the Sprint Backlog.

That's how I read it.

Pat

Going over Scrum Guide p11 again, it seems that sprint goal also answers the question 'why'. It is kind of a starting point for the sprint. So the sprint goal answers what we are doing and why we are doing it now. The sprint backlog fills in how part. 

Selçuk

Sprint Backlog is reflection of the Sprint goal. If the sprint goal becomes obsolete the sprint will be cancelled and hence backlog will make no sense.

Hence Sprint backlog is created after deciding on the goal by understanding which business object the PO should fulful in upcoming (this) sprint in sprint planning.  

Hence - Goals are set BEFORE the individual objectives.

Why does it matter if it is "before" or "after" sprint backlog is created?

Sprint Backlog is created to fulfill the Sprint Goal and therefore you cannot create the Sprint Backlog if you don't know the Sprint Goal.  Remember that the Sprint Backlog does not have to be fully created and often isn't during Sprint Planning. Just enough to get started.  The Spring Goal drives what will be pulled into the Sprint Backlog from the start and drives the discussion in Planning, etc.  If you were to start pulling in work and then define the Sprint Goal, the goal would be based on what was selected, not the selection based on a goal. Remember, we are pushing toward a goal, so the goal is defined to choose the work, not the goal retrofit to fit the already selected work.

It's a bit of both, ideally.

If you can come into Sprint Planning with a Sprint Goal in mind (written or not) that makes things easier but it's not required. When the Scrum Team builds the Sprint Backlog...at some point Capacity should be considered. If capacity requires the Sprint Backlog to adjust, then consider adjusting the Sprint Goal.

I like to think that the goal of Sprint Planning is finalize or align the Sprint Backlog with the Sprint Goal and only when that is complete could the team be ready to start doing the work. So it's not one or the other. 

Thanks Ian Mitchell, for the precise and to the point answer.

> So final answer is "Sprint Goal is create BEFORE Sprint Backlog ?

Be careful when you talk about the Sprint Backlog being "created". The Sprint Backlog serves the purpose of meeting the Sprint Goal, and its ability to do so must be improved at every opportunity during the Sprint.

Thanks Rajat ji for an elaborate outlook, particularly sharing your real time experience where Sprint Goal is created by Product Owner well before Sprint Planning. 

Interesting conversation. While comparing between Sprint Backlog and Sprint Goal, Indeed the Sprint Goal is decided before the Sprint Backlog. In fact, based on my experience it is decided much earlier by the Product Owner  i.e. before the "Sprint Planning" meeting by him managing the Product Backlog Items throughout the product lifecycle. 

I agree Sprint goal is created before selecting the sprint backog items because it is the light to conduct the Sprint, but what about product backlog items picked by developers?

the PBi are reasonable ordered by PO (and maybe ready), could it be that developers choose some items not exacly at the top of product backlog and not yet well ordered because they believe they meet the sprint goal?

at the end, they can refine in the sprint planning meeting if they are pretty sure those will fit the Sprint goal (and maybe cross them out during the sprint if they recognise those don't match the sprint goal at all - always under discussion with PO), correct?

Thanks

Flavia

From my perspective creating a Sprint Goal is rather a collaborative work of the entire Scrum team that is driven by the Product Goal. I don't think of the Product Backlog as a list that is "frozen" when it comes to Sprint Planning. I rather see it as a continuously evolving artifact.

As a Product Owner, wouldn't I always try to put the most valuable items on top? I don't see an issue with changing the  order of the PBIs even when the whole Scrum Team collaborates to create a Sprint Goal during Sprint Planning. And if I realize during Sprint Planning that "items #1 + #3 + #5" from my Product Backlog list are actually the most valuable (ideally "ready") items and they are a perfect fit for the Sprint Goal... would there be any reason to not make these my new top items instantly when planning the Sprint?

This really is a fascinating discussion! I think we all agree the Sprint Goal comes before the Sprint Backlog however, when the Sprint Goal is created does seem to be an item of contention.

It definitely seems like a good idea to have an initial idea of what you want to deliver before you select items or as Eric Naiburg completely nailed it, you end up just fitting a Sprint Goal to the items you've selected and that is highly dysfunctional. 

The Product Owner proposes how the product could increase its value and utility in the current Sprint and then the team comes up with a Sprint Goal. Pretty tempting to just tell the team the Sprint Goal right? I guess this is a question of divergence and convergence and letting the team think and innovate a little before they agree on the Sprint Goal collaboratively. 

Anyway the way I read it is, the Product Owner says what they think will be most valuable to their user next, then they could challenge the team to try and interpret a suitable sprint goal from that. Close enough is probably good enough. 

Then the team choose some backlog items that align with that goal and at the end they revisit the goal, tweak it, challenge the items that don't fit it, then commit to the sprint?

I think we all agree the Sprint Goal comes before the Sprint Backlog

The Scrum Guide makes it clear that the Sprint Goal is created during Sprint Planning, and is one of the things from which the Sprint Backlog is composed. There is no prescription about whether it is crafted before, during, or after the rest of the backlog has emerged, and I'd suggest that's something a creative team might well take advantage of.

I read the scrum guide as follows

1 The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.

2 the Developers select items from the Product Backlog to include in the current Sprint that are needed to achieve the sprint goal.

If during step 2 the team comes to the conclusion the sprint goal can not be achieved during 1 sprint they update the sprint goal (inspect and adapt)

And at the and of the meeting the sprint goal is final 

So my conclusion is that the sprint goal can adapt during the sprint planning and is not frozen before the sprint backlog is created but is frozen/agreed/committed at the end of the sprint planning

For the product owner:

If you come into a sprint planning with a sprint goal that is immutable, you're not being very agile.  You'll have to flex it based on what is picked and what the scrum team decides.

If you come into a sprint planning with no clue what a candidate for the sprint goal is, you're not very organized.  You should be refining the product backlog in a way that makes sense, which is often by creating at least an idea of a sprint goal.

I've seen people come into a planning and the product owner and team craft and refine the sprint goal and then decide what the plan to meet that goal is by creating a sprint backlog.  That works great with mature scrum teams. 

Thx for sharing information!

Nice topic for discussion. Thats why I see it started in 2014 and still going...

As per Scrum guide 2020, the topic one in Sprint planning is to align on 'Why is this sprint valuable ?'.

My interpretation of it is the Scrum team discuss about 'why' part of sprint and the outcome will be sprint goal.At the same time, Sprint goal is subjected to get adjustments during the 2nd and 3rd topics of Sprint planning that are 'what' and 'how' part.Because it is also given in the sprint guide that"The Sprint Goal must be finalized prior to the end of Sprint Planning."

In scrum guide, There is no mentioning of 'Sprint goal' in the "What can be done this sprint ?" topic of sprint planning. (In this step, the team select items from the product backlog to include in current sprint). So does it means, Sprint goal is not directly talk about the increments developed from backlog items ? (like completing a ecommerce feature,,,), But the value that will be added to the product which we can measure using EBM(Evidence Based Metrics) ?

Its a nice thread of discussion.

Scrum Guide 2020 says: The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog.

Does it mean Sprint Backlog existed already, we created Sprint Goal and added it to Sprint Backlog?

Hi Meenu

The Sprint Backlog is comprised of a few things: Sprint Goal, Product Backlog Items and a plan.

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

Sprint Planning Event is broken down into numbered topics. Topic One is about the Product Owner proposing how to increase value for the product and the Scrum Team defining a Sprint Goal (Why). Following this we have Topic Two which is selecting Product Backlog Items needed for that goal (What). Topic Three is a plan (How)... 

Topic One: Why is this Sprint valuable?

The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.

Topic Two: What can be Done this Sprint?

Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.

Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.

Topic Three: How will the chosen work get done?

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. 

Building the Sprint Backlog:

1. Sprint Goal (Why)
2. Product Backlog Items needed for Sprint Goal (What)
3. Plan for delivering Increment (How)

Ideally the PO would come up with the Sprint Goal during the Sprint Planning and then the Developers would check what PBIs from the Product Backlog need to be completed to achieve the Sprint Goal. If it seems not doable there could be discussions back and forth to come to an agreement and finalize a Sprint Goal which everyone commits to. This is normally what happens during our Sprint Planning sessions. Do suggest any improvements if required.

I really don't understand the plenty literature. It is a simple question.

"Is The Sprint Goal selected BEFORE or AFTER the Sprint Backlog is created?"

Answer: Before.