Sprint Goal vs Product Backlog prioritisation. How do the two agree?

In my opinion, the Sprint Goal has nothing to do with ordering of the backlog.  The backlog is ordered based on what the PO determines is the best method.  Prioritization may not be the best method. I have not heard your statement about ordering of the backlog for 2 sprints.  I have heard, and advocate, refining items for 1-3 sprints at the top of the backlog.  In reality the entire Product Backlog should be ordered at all times.  It can (and usually does) change frequently so ordering is a part of the constant management. 

The Sprint Goal is used to communicate what the Development Team wants to accomplish and deliver in the sprint. It should be constructed in collaboration with the Product Owner but it is ultimately the Development Team that owns it.  It should embody the main theme of the stories selected but does not necessarily have to encompass all the stories.  We frequently will pull in some kind of technical debt that is not related to the new functionality we are working to build.  Our Sprint Goal will cover the new functionality but not the technical debt.  If our entire sprint is focused on technical debt, then the Sprint Goal is also focused there. 

The purpose of the Sprint Goal is to give the Development Team a way to focus their work.  It helps in determining impediments because you have something larger than a single story to measure against. It also helps to communicate to the rest of the Scrum Team what they wish to accomplish.

Can you provide an example of how having a Sprint Goal can clash with taking items from the top of the Product Backlog?

According to the Scrum Guide, your Sprint Goal is "an objective set for the Sprint that can be met through the implementation of the Product Backlog" and that it is something that "provides guidance to the Development Team on why it is building the Increment". If your underlying objectives are to ultimately deliver the maximum value and your Product Backlog is ordered in such a way that the top of the Product Backlog represents the things that lead to the most value being delivered, then your Sprint Goal should generally align with the Product Backlog. However, the advantage comes in when the team pulls in additional work. The Sprint Goal helps to remind the team what is most important. If work is discovered as the Sprint goes on or if unexpected things happen, it lets the team organize itself around the things that are the most important to the stakeholders.

I don't understand how that doesn't clash with the ideal of being able to take items from the top of the Product Backlog each sprint and shifting them straight into the Sprint Backlog.

Why do you think that this behavior would represent some sort of ideal? Mightn't it be better to have a selection of "ready" items available for planning?

Thank you all for your replies.

@Daniel Wilhite

Apart from saying that I agree that the Sprint Goal has nothing to do with the ordering of the PB, the rest that I would write in response to your post will be part of my general reply.

@Thomas Owens

As an example, if the next sprint holds the top 9 PBIs, and of them 3 involve user interface improvements, 3 involve 3D simulation, and 3 involve bug fixes to do with hardware, I wouldn't know how a Sprint Goal could exist that doesn't clash. _Unless_ the Sprint Goal is superfluous, along the lines of "The Sprint Goal is to do the items that were selected to be done."

If your underlying objectives are to ultimately deliver the maximum value and your Product Backlog is ordered in such a way that the top of the Product Backlog represents the things that lead to the most value being delivered....

... let's assume this is always the case. I'm not sure, but if you're suggesting this is not always the case could you please elaborate.

... then your Sprint Goal should generally align with the Product Backlog. 

I'm not sure which "should" you are using: likely or obligated. If "likely", I don't understand how you got to that conclusion. If "obligated", I can agree but I don't think it's answering the question.

@Ian Mitchell

I already assume there is a selection of ready items as part of my question. Taking items from the top of the backlog is referring to the ideal of sprints consuming PBIs in their order of prioritisation. Items that are already ready.

As my general reply and to clarify my question further --



Uncertainty 1:

* Does the Sprint Goal influence in any way the PBIs that will be pulled into a sprint during sprint planning?

* Does the Sprint Goal influence in any way the PBIs that will be pulled into a sprint when the team is ahead and more work has to be pulled in?

If the answer to both is no, it looks like the Sprint Goal is really only a Sprint Summary; it's not leading, only reflecting.



If the answer is yes in any way, then it sounds odd to me that it means the team is negotiating PBI priorities with the PO.

Uncertainty 2:

It communicates the reason for carrying out the work. "Why is it worthwhile to run the sprint?"

Isn't the reason for carrying out the work simply to get the work done? I mean, the project is already sold, it must go ahead. Isn't the reason for carrying out this sprint's _particular_ work simply always because that particular work was chosen as the priority?

Could someone give an example of a PB that has a number of unrelated items prioritised at its top, and a Sprint Goal that works with that?

 

Taking items from the top of the backlog is referring to the ideal of sprints consuming PBIs in their order of prioritisation

Are you quite sure that consuming PBIs in their order of prioritisation represents an ideal? Remember that a Product Owner can order the Product Backlog by whatever criteria he or she likes.

Might it not be better, during Sprint Planning, to have a selection of “ready” items, so that the team can make a choice about which of them will be actioned and what the associated Goal will be?

Going to remind you that this is just my opinion and interpretation of the Scrum Framework and Agile practices. It is based on my experience.  Others will most likely have differing opinions and experience. I encourage you to take our input and form your own interpretation.  That is what Agile and Scrum advocate since their basis is Empiricism. 

In the example you provided @Thomas, I would ask you which of those 3 areas are considered the most important to the company and the value provided by doing the work on the product?  The answer to that question will help to guide the team in crafting the Sprint Goal.  

My response to your Uncertainty #1

There is no where in the Sprint Guide that says when the Sprint Goal is crafted during the Sprint Planning.  It only states the purpose of the 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.

What is to stop the team from crafting the goal after they have forecasted a set of stories to be included in the Sprint? Why can't the goal encompass multiple areas of work if those areas have been deemed important enough to be forecasted as work for the next timebox?  

...that it means the team is negotiating PBI priorities with the PO.

No, they are not negotiating PBI priorities.  They are defining the work that needs to be done in order to satisfy the PBIs.  It is quite possible that the team cannot do PBIs 1,2,3,4 from the backlog due to dependencies of some kind.  In that case, I would expect them to look at items 5,6,7,.... to find work that is possible to do during the time box and still provides value to the organization/stakeholders/users.  No one wants to sit idle just because they finished some work.  And no company really wants that either.  

My response to your Uncertainty #2

Isn't the reason for carrying out the work simply to get the work done? I mean, the project is already sold, it must go ahead. 

In Agile and Scrum the reason for carrying out the work is to provide incremental value to the stakeholders. The project may be exploratory, it could be maintenance, it could be new functionality.  But regardless of what kind of project, it is being done to provide some kind of value to the stakeholders. Does it have to go ahead?  No.  It can be stopped based on information found during the execution of the sprints.  What if you discover that there is no existing technology that can support what you need to do? What if you find out that you can create the feature but the effort to maintain it is greater than the organization is willing to commit?  What if the stakeholder decides to change their direction and the work is no longer needed?  You have been incrementally providing value, so what if the stakeholder decides that their original request is not longer needed because you have already delivered enough value? There are many reasons that "the project" might no go ahead. So, as I said before the purpose for carrying out the work is simply to provide incremental value to the stakeholders. 

Isn't the reason for carrying out this sprint's _particular_ work simply always because that particular work was chosen as the priority?

As I said in my response to Uncertainty #1, the sprint's _particular_ work might not be chosen based on the order of the backlog items.  It is according to the Development Team's decision on how the work makes best sense to do based on the technical restrictions. All of the items included in the Sprint Forecast should provide value and should be included in the Product Backlog.  The Product Backlog should include all work that has been determined to provide additional value to the product's stakeholders.  But the purpose doing the sprint's work is to create an potentially releasable increment of work that provides value to the stakeholder, not just to do work that has been said to be priority. Yeah, it is a fine line but in order to appreciate Scrum, you have to be able to understand and recognize the difference. 

As an example, if the next sprint holds the top 9 PBIs, and of them 3 involve user interface improvements, 3 involve 3D simulation, and 3 involve bug fixes to do with hardware, I wouldn't know how a Sprint Goal could exist that doesn't clash. _Unless_ the Sprint Goal is superfluous, along the lines of "The Sprint Goal is to do the items that were selected to be done."

Of those things - user interface improvements, implementing 3D simulation, or bug fixes, is the singular most important thing in the Sprint? That would be your Sprint Goal. Then, if you need to make trade-offs between delivering the user interface improvements, the 3D simulation, or the bug fix, it's crystal clear to the team as to which one gets the attention. Perhaps, as the Sprint goes on, it becomes clear that one is far more involved or complex than the team initially thought and all of the work can't be done, so the Sprint Goal gives insight for the team to be able to focus their work on delivering something of value. It's also very clear to stakeholders what they can expect to receive by the end of the Sprint.

Thanks for the replies again, all.

@Ian Mitchell

I don't want to focus on the meanings of ideal or priority too much here. What I'm questioning is whether the team, in defining a Sprint Goal, is manipulating the order in which items in the PB are consumed. Your answer appears to be "yes". 



This is the situation where I find that the concept of a Sprint Goal does make simple sense. But is is also the situation where I am surprised to hear that the PO might want to say X is more important than Y, but the team tells the PO they intend to leave X until a later sprint because it doesn't currently fit a Sprint Goal.

By the sounds of it, you're saying yep, this is a thing that is normal.



 

@Daniel Wilhite

Considering things from the other direction though, you have written this:

What is to stop the team from crafting the goal after they have forecasted a set of stories to be included in the Sprint?

Because if it isn't influencing which work is selected, it's a summary, not a goal.



Now perhaps the set of Sprint Items does actually transmit a clear theme. That's fine; that works as a guiding light enough to be identified as a "goal" (even though identifying is still not the same thing as crafting). But this is a nice case; it's a rarity in my experience and not the case I'm concerned about in this thread. I'm open to being told that this shouldn't be a rarity, which would probably leave me feeling some closure but I would still walk away thinking someone mis-named "Sprint Summary".

Why can't the goal encompass multiple areas of work if those areas have been deemed important enough to be forecasted as work for the next timebox?  

Because the only way that "deemed important enough to work on next" also means "can fit a common goal" is to accept that the goal can be so loosely defined that it is too meaningless to be worth the conversation. We would always have a Sprint Goal of "doing the most important work in the PB". PBIs that are similar aren't always valuable to do together (due to dependencies, parallelisation, for example).

My response to your Uncertainty #2. ...

My focus of this Uncertainty #2 was the Sprint Goal's purpose that had I quoted with it. I was questioning the comment I had quoted, which said  "[The Sprint Goal] communicates the reason for carrying out the work". I wasn't questioning a general "Why are we doing work". That said, I have no disagreement with anything you wrote from this point.

@Thomas Owens

Of those things - user interface improvements, implementing 3D simulation, or bug fixes, is the singular most important thing in the Sprint? That would be your Sprint Goal. 

The 2 problems I see with this are:

1. Similar to what I mentioned above, this is then a summary more than it is a goal. It still smells like a shoehorn. I do believe I understand the idea you're expressing: one important element of focus is being identified to guide later decision-making,. But as long as you're saying that this is coming after the fact (ie., a bunch of items are selected and the team is then saying "Ok, area <blah> looks like it has enough presence to call a goal")  then I really do not see how it is valuable. Because when it comes to trade-offs, pulling in future work, or anything along those lines, what is the team going to do: consult the summary they labelled "Sprint Goal"? Or consult the PO and their priorities (which they have put time into defining).



2. It works if all PBIs in those 3 groups have their priorities next-door to each other, and if trade-off-able work / extra PBIs agreeing with a Sprint Goal also have similar priorities. That is frequently not the case.





______________________________________________________





As we can see, I'm still feeling like there are problems with every perspective of the Sprint Goal that has been suggested. 



Ian's perspective is the one I find most understandable, but I still question what this means for the weight that the team is throwing around when it comes to denying the PO's preferences for what gets done first.



And I do wonder if the replies here are on different pages.

So I'll repeat a question I ended last post with:

Does the Sprint Goal influence in any way the PBIs that will be pulled into a sprint during sprint planning?

When making these assumptions:

• that a number of "ready" PBIs exists
• they are all unblocked
• they are ordered by the PO's order of importance
• they support a releasable increment of the product in any combination

Are people more yes, or no, on the above question?









 

I still question what this means for the weight that the team is throwing around when it comes to denying the PO's preferences for what gets done first.

It would mean that the Scrum Team had issues with collaboration, and that the problem ought to be addressed before Sprint Planning can be effective.

So I'll repeat a question I ended last post with:

"Does the Sprint Goal influence in any way the PBIs that will be pulled into a sprint during sprint planning?"

The Scrum Guide says:

"The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team."

That's it. Those are the inputs to Sprint Planning. There's nothing about a narrowed set of items from the Product Backlog or a goal which will shape the selection. The Sprint Goal and the Sprint Backlog may thus be elicited, during Sprint Planning, in a mutually supportive way such that they influence each other.

I agree sprint goal and sprint backlog influence each other and we have come back often to scrum guide.

Sprint goal is something what tells us what is most important especially as you know you don't have enough time to do all items from sprint backlog.

It's a similar situation as in real live when in one moment you have many potential adventages around you and you have to choose only one. Your goal is the first and the last thing about which you have think and remember. 

Hi

Additionaly I want to remind what scrum guide says:

"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."

So I think a PO should provide a development team proper both sprint backlog and sprint goal. 

I think the discussion became somehow too detailed and we're missing a key distinction here:

Daniel,

My response to your Uncertainty #1

There is no where in the Sprint Guide that says when the Sprint Goal is crafted during the Sprint Planning.  It only states the purpose of the goal.

There is actually a paragraph that reads:

"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."

@Jesse, here's an example of my current practice (as others have pointed out, this is just my practice and understanding)

• We have a product and a product backlog (this contains hundreds of stories and bugs).
• We run 2 or 3 refinement sessions where the entire DT and a few key business people (of which PO is the main one) discuss the business needs - stories are created ad hoc; existing stories are discussed and estimated; bugs are also looked into and prioritized
• PO is constantly and continuously ordering the backlog. We always have at least 10-15 stories estimated and ready to be picked up 
• Our aim is to have enough work estimated for at least a sprint ahead, so that during planning we only discuss the What & How; if there are urgent items (business requirements) we cover those during planning and either create or update PBIs, estimate and discuss importance.
• Once in planning, the PO discusses what the business would need in that particular development cycle by referring to the actual PBIs, and the DT reviews and decide what can be covered, and they pull it from the PB into the SB. Note that we almost always have the top of the PB already estimated, hence we move quite fast.
• Once PBIs are pulled into SB, those become SBIs, and we, as a team, draft a sprint goal. The sprint goal refers to the most important item(s) that address a business need (regardless of the angles of that need). Other than the SBIs that are "part of" the sprint goal, we usually have other items (bugs, tasks) that the team decided to take into sprint.
• We also provide production support, which means that we've got to leave some room for potential problems that require the team's attention. We allocate about 10% to those. If nothing happens, we discuss and the DT usually pulls something else from the PB. If something happens, we're covered, in theory (10%); if the reality is different (very complex/critical production issues), we discuss and adapt.

So, to answer your initial question,

In other words, what happens when prioritisation and Sprint Goal don't agree? One of these two things has to give; isn't something going to get shoehorned?

I think it's fair to say there's no "disagreement" between what you refer to as prioritisation and the sprint goal. It's all about being flexible/adaptable, taking a decision at the best moment (LRM), and responding to change if and when it happens.