Open Scrum test question discussion: adjusting Sprint Backlog during sprint

B is indeed the correct answer - the review and adjustment of the Sprint work or Sprint scope is a collaboration between the Development Team and the Product Owner. The Scrum Master may be asked to facilitate, but is not required.

It's true that the Development Team is responsible for the Sprint Backlog. But the key is the forecast will not be met. Another way of putting it is that not all of the Product Backlog Items selected for the Sprint will be complete. Since the Product Backlog, the Product Backlog Items, and the ultimate delivery of value to the stakeholders is the responsibility of the Product Owner, changes that impact what Product Backlog Items will be delivered need to include the Product Owner.

The changes could range from trying to determine which Product Backlog Items should be removed from the Sprint scope to reducing the size and scope of Product Backlog Items so that way something can be done to obtain feedback while ensuring what is done is something that is still potentially releasable. In many cases, the Development Team can't unilaterally make these decisions.

The Sprint Goal is another useful construct. With a well-crafted Sprint Goal, the Development Team can make more decisions on their own. They would be able to prioritize work necessary to achieve the Sprint Goal while deprioritizing unrelated Product Backlog Items. Unless the Sprint Goal was in jeopardy, the Development Team could have more freedom to determine what work to do without involving the Product Owner.

note that the question only says that the forecast will not be met, and not that the Sprint Goal will not be achieved

The question couldn’t really assert that the Sprint Goal will not be achieved, because that would mean predicting a given outcome with certainty. That’s why the ability to project a forecast of work during a Sprint is important.

Since the Sprint Backlog provides a forecast of the Product Backlog items needed to achieve the Sprint Goal, and the Goal and selected items are planned in agreement with the Product Owner, he or she ought to be present if the selection is revised. The Goal may no longer be viable in the PO’s view.

I agree to the points made above though a few questions came to my mind as I was preparing to reply.

First, the below line from the Scrum guide seems to suggest that the PO is responsible for the objective of the Sprint and therefore the Sprint Goal. Is there a difference between Objective and Sprint Goal?

The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal

Second, under the same section of the Scrum guide, the below line states that the Scrum Team crafts the Sprint Goal.

During Sprint Planning the Scrum Team also crafts a Sprint Goal.

Shouldn't the PO be the one crafting the Goal? What role does the SM have in terms of crafting the Sprint Goal if it is indeed the Scrum Team that crafts the Sprint Goal? 

Lastly, if a forecast is not met, and assuming that the feature/functionality/work/increment that was supposed to be delivered at the end of the Sprint is still needed by the business, then would the next Sprint also have the same Sprint Goal? i.e. to accomodate the incomplete/carryover work from the previous Sprint? Another way to ask is, if the Sprint Goal of the previous Sprint is not met and the functionality/work is still of value or still needed, and assuming that to complete that work we only need 2-3 days of the next Sprint (assume 2 week Sprint), how would the Sprint Goal be crafted for the next Sprint without losing the remaining days? My understanding here is that a Sprint Goal is a single cohesive objective and not multiple objectives.

With a hypothetical example, I hope I can clarify my thoughts further.

Product Objective: Deliver Feature 1 and Feature 2

Sprint 1 (2 weeks) Sprint Goal: Deliver Feature 1. 

Feature 1 has 20 stories/tasks.

Sprint 1 End: 17 stories/tasks completed

Sprint 2 (2 weeks) Sprint Goal: Deliver Feature 2 and Carryover work from Sprint 1

Does the above seem correct? If not how should it be handled? Both features are needed, there is no question of re-visiting its value or if it is still needed.

Thanks for diving in Thomas and Ian - your insights are enlightening as always, and I agree, or at least, I think I do :)

I guess I'm just reading the question differently. In the overwhelming majority of the cases, the Dev Team and the PO would of course collaborate on mitigating emerging trouble regarding the achievement of the forecast. Especially if you read that as endangering the Sprint Goal. But I read this question to be about the minimal set of roles necessary to change the Sprint Backlog, and as such, I'm still not convinced :)

If the question would have been "During a Sprint, a Development Team determines that it may not be able to finish the complete forecast and that the situation may jeopardize the Sprint Goal. Who should be present to review and adjust the Sprint work selected?" or something like that, B would be more obvious.

In many cases, the Development Team can't unilaterally make these decisions.

"In many cases", well, that's the thing. In those cases where they can not, then they should have access to the PO and would be expected to tap that important resource for keeping value delivery optimal. But if they can make unilateral decisions, especially if they can still achieve the Sprint Goal, I still doubt why the PO's help would still apparently required by definition. (Although the PO may raise the issue of why they weren't consulted during a retro, which would be a good topic of discussion and possible area of improvement for reciprocal expectations/agreements.)

They would be able to prioritize work necessary to achieve the Sprint Goal while deprioritizing unrelated Product Backlog Items. Unless the Sprint Goal was in jeopardy, the Development Team could have more freedom to determine what work to do without involving the Product Owner.

This seems to underline my point when I'm saying that the forecast not being met (per se) does not necessarily jeopardize the Sprint Goal. If it does, then the PO should be involved rather sooner than later.

I agree to the points made above though a few questions came to my mind as I was preparing to reply.

I will read your additions to the discussion and may respond separately :) Thanks.

Is there a difference between Objective and Sprint Goal?

Yes, in so far as the Sprint Goal cannot be changed, whereas any objective the PO has when entering Sprint Planning might change following discussion with the team.

Second, under the same section of the Scrum guide, the below line states that the Scrum Team crafts the Sprint Goal.

During Sprint Planning the Scrum Team also crafts a Sprint Goal.

Shouldn't the PO be the one crafting the Goal?

Not without the involvement of Development Team members, because they will be the ones doing the work, and they will be expected to commit to achieving it.

What role does the SM have in terms of crafting the Sprint Goal if it is indeed the Scrum Team that crafts the Sprint Goal?

The SM’s service to the PO includes ensuring that the Sprint Goal is understood by the team. By the end of Sprint Planning, the Development Team should be able to explain to the SM that they have a viable way to meet it.

Lastly, if a forecast is not met, and assuming that the feature/functionality/work/increment that was supposed to be delivered at the end of the Sprint is still needed by the business, then would the next Sprint also have the same Sprint Goal?

Not necessarily, because the next Sprint represents an inspect-and-adapt opportunity to craft a new Goal based on lessons learned.

i.e. to accomodate the incomplete/carryover work from the previous Sprint?

Incomplete work ought to be re-estimated on the Product Backlog, rather than “carried over”. Bear in mind that a learning opportunity is presented.

Another way to ask is, if the Sprint Goal of the previous Sprint is not met and the functionality/work is still of value or still needed, and assuming that to complete that work we only need 2-3 days of the next Sprint (assume 2 week Sprint), how would the Sprint Goal be crafted for the next Sprint without losing the remaining days?

Even if the Goal for that Sprint remained the same as that of the previous Sprint, and only occupied the Development Team for a small portion of their time, there is no reason to believe days would be “lost”. The team could reasonably plan to action other work unrelated to the Goal.

The SM’s service to the PO includes ensuring that the Sprint Goal is understood by the team. By the end of Sprint Planning, the Development Team should be able to explain to the SM that they have a viable way to meet it.

@Ian Mitchell, but why should they explain to the SM? The PO represents the business side of things, wouldn't it be more apt for them to explain to the PO that they are able to achieve an increment within the duration of the Sprint?

Incomplete work ought to be re-estimated on the Product Backlog, rather than “carried over”. Bear in mind that a learning opportunity is presented.

Ideally, yes, unfinished work should be added to the backlog and re-prioritized, but as I mentioned if we know that this work is definitely needed, does it make sense to move it to the Product Backlog, when it could directly be a part of the next Sprint Backlog. Perhaps, this is a bad practice because we use electronic tools, and the moment we realize some work cannot be finished by the end of the current Sprint, then that can be picked up as part of the next Sprint. The assumption here is that this is work that is definitely needed, not something that may become obsolete or unwanted after a Sprint Review with the relevant stakeholders.

Even if the Goal for that Sprint remained the same as that of the previous Sprint, and only occupied the Development Team for a small portion of their time, there is no reason to believe days would be “lost”. The team could reasonably plan to action other work unrelated to the Goal.

This is something I wasn't aware could be done. I thought it went against the rules of Scrum. I understood it as the Sprint Goal should be accomplished by PBI's that are coherent.

The team could reasonably plan to action other work unrelated to the Goal.

If the Team does work on a coherent set of PBIs to accomplish a Sprint Goal in one Sprint, but works on non-coherent PBIs in another Sprint such that they don't have a relevant Sprint Goal. Would you say the team is practicing Scrum? or did they practice Scrum in one Sprint and not in the other? Let's say this pattern has a re-occurence but is random, would we say that overall the team is practicing Scrum or would we say that the team is inconsistent with Scrum but is following it as closely as possible?

but why should they explain to the SM? The PO represents the business side of things, wouldn't it be more apt for them to explain to the PO that they are able to achieve an increment within the duration of the Sprint?

They need to be able to do both, bearing in mind that the SM provides a relevant service to the PO. The Scrum Guide says:

"By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment."

The Guide also says:

"The Scrum Master serves the Product Owner in several ways, including:

• Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible;"

does it make sense to move it to the Product Backlog, when it could directly be a part of the next Sprint Backlog.

The Product Backlog should show how much work is currently believed to remain for the Product. Work is not really "moved" from one backlog to the other in either direction. In Scrum we often allude towards doing so, but this language is not strictly correct. Rather, work is re-estimated on the Product Backlog so the amount believed to remain is captured as accurately as possible. The next Sprint Backlog does not exist until the next Sprint begins.

I understood it as the Sprint Goal should be accomplished by PBI's that are coherent.

The Sprint Goal can be any coherence which gives the team a reason to work together. Scrum does not require that all of the Product Backlog items selected in a Sprint must be essential to the Sprint Goal. If a team anticipates that contingency is likely to be needed if the Goal is to be achieved, for example, then they may reserve a portion of their Sprint Backlog for unrelated work. All of the PBI's selected in the Sprint Backlog would nevertheless provide coherence in terms of Sprint Goal realization.

The Product Backlog should show how much work is currently believed to remain for the Product. Work is not really "moved" from one backlog to the other in either direction. In Scrum we often allude towards doing so, but this language is not strictly correct. Rather, work is re-estimated on the Product Backlog so the amount believed to remain is captured as accurately as possible. The next Sprint Backlog does not exist until the next Sprint begins.

@Ian Mitchell, In theory yes, but in practice those incomplete stories either end up in the Product Backlog (if they are not needed in the next Sprint or immediately) or in the next Sprint. As I mentioned it could be a bad practice because of the way we use an electronic tool. In the cases I've experienced, the next Sprint Backlog/Board is available in the electronic tool, even before the current Sprint has ended. In such a scenario, the tendency is to move the Story/Stories (the work) to the next Sprint makes sense vs. moving it to the Product Backlog knowing very well that these stories have to be done no matter what and if we have to use the next Sprint to do that, then that is what we have to do.

The below line from the Scrum Guide is where the tendency to say "moved to the next Sprint" or "moved to the Product Backlog" comes from.

All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.

If we know the incomplete items are still needed, is it necessary to go through the motion suggested by the above line i.e. put it back to the Product Backlog while using an electronic tool, when we can put it directly into the next Sprint Backlog?

Also, is it always necessary that the work done depreciates quick? It may or may not depreciate right? It depends on the situation I guess.

Btw, Thanks for taking the time to reply back and for clarifying these aspects. It is much appreciated.

A follow up question... If the choices for the question in the original post were modified as below, would the correct answer be A? If No, then why?

During a Sprint, a Development Team determines that it will not be able to finish the complete forecast. Who should be present to review and adjust the Sprint work selected?"

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

Answers:

A) The Scrum Master, the Product Owner and the Development Team.

B) The Product Owner and the Development Team.

C) The Product Owner and all stakeholders.

D) The Development Team.

Also, can a Sprint Goal be met even if some items in the forecast are not done? What should be the next steps if the Sprint Goal is not met? Do we start another Sprint with the same Sprint Goal (assumption here is that the Goal has to be achieved in the shortest possible time, given the current scenario, Meeting the Goal is mandatory)

During a Sprint, a Development Team determines that it will not be able to finish the complete forecast. Who should be present to review and adjust the Sprint work selected?"

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

Answers:

A) The Scrum Master, the Product Owner and the Development Team.

B) The Product Owner and the Development Team.

C) The Product Owner and all stakeholders.

D) The Development Team.

I would argue B is the correct answer. The Scrum Master would only be present if requested by the Product Owner and/or the Development Team. I would also suggest that the Product Owner's involvement may change depending on if the Sprint Goal was in danger or not, where the Product Owner would be more likely to be an active participant (rather than just informed) when the Sprint Goal is in danger.

Also, can a Sprint Goal be met even if some items in the forecast are not done? What should be the next steps if the Sprint Goal is not met? Do we start another Sprint with the same Sprint Goal (assumption here is that the Goal has to be achieved in the shortest possible time, given the current scenario, Meeting the Goal is mandatory)

Yes, the Sprint Goal can be met even if some items from the Sprint Backlog are incomplete. It's not a requirement that all Product Backlog Items for a Sprint directly related to the Sprint Goal.

If the Sprint Goal is in danger of not being met, there are a few options. The Scrum Guide suggests cancelling the Sprint, but the cancellation of a Sprint is considered "traumatic". In addition, if you have multiple teams working toward a single product increment, then cancelling the Sprint for one team may not be feasible. However, there are opportunities to ensure that there is a fully integrated, demonstrable, potentially releasable product increment at the end of the Sprint. Exactly what I would recommend is highly context sensitive.

If we know the incomplete items are still needed, is it necessary to go through the motion suggested by the above line i.e. put it back to the Product Backlog while using an electronic tool, when we can put it directly into the next Sprint Backlog?

The Product Backlog should always indicate how much work is truly believed to remain, so useful forecasts can be made. If this is best achieved by “putting work back” in preparation for Sprint Planning, then so be it. If a tool allows this “step” to be bypassed then the consequences for transparency and planning will have to be understood and managed. 

Also, is it always necessary that the work done depreciates quick? It may or may not depreciate right? It depends on the situation I guess.

If completing a certain item isn’t of greater value now than it would be if left until later, why prioritize it above other work and plan it into a Sprint?

From the Scrum Guide, the below line,

During Sprint Planning the Scrum Team also crafts a Sprint Goal.

@Thomas Owens, If the Scrum Team crafts the Sprint Goal, why wouldn't the Scrum Team also be present to review a forecast that that cannot be met?

Similarly, If the Sprint Goal is in danger of not being met, why would the active participant be the Product Owner and not the entire Scrum Team?

In the original choices, the only option that is correct was B. The Product Owner and the Development Team.

Yes, the Sprint Goal can be met even if some items from the Sprint Backlog are incomplete. It's not a requirement that all Product Backlog Items for a Sprint directly related to the Sprint Goal.

I should've been a little more clear. If the Product Backlog items forecasted to meet a Sprint Goal are the only ones in the Sprint Backlog, and if some of them are not met, can we still meet the Sprint Goal? I think I answered my own question in the process. See below line from the Scrum Guide.

The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal.

Also,

If the Sprint Goal is in danger of not being met, there are a few options. The Scrum Guide suggests cancelling the Sprint,

Why would we cancel a Sprint just because the Sprint Goal wasn't met? Do you reckon what the Scrum Guide suggests regarding Sprint cancellation is when the Sprint Goal becomes obsolete?

If completing a certain item isn’t of greater value now than it would be if left until later, why prioritize it above other work and plan it into a Sprint?

@Ian Mitchell, I believe I understand what you are saying and I agree with you,

Perhaps I am not able to articulate better what's on my mind :)

Let's try one last time...

Let's say our Business sponsor wants us to deliver a new type of Car, new engine etc. and wants to get it in working condition ASAP. Ideally, he wants it to be ready in less than a month. Let's assume we're in a 2 week cadence.

Let's say that our Sprint Goal is To deliver a working car that meets the requirements of the sponsor.

So we enter Sprint 1 assuming we can complete this task

On the Day of the Sprint Review, the car does not start for some reason and the engineers are unable to resolve the issue. Along with this, the business sponsor does not like the cloth upholstery on the seats and prefers to go with Leather. He also notices that the car hasn't been painted.

So, we enter Sprint 2, knowing we didn't technically meet the goal of the previous Sprint. In Sprint 2 our Goal is still to to deliver a working car that meets the requirements of the sponsor. In this Sprint though we need to make sure that the starting problem which wasn't previously there is permanently resolved,the upholstery is changed and the car is painted as per the feedback received from the sponsor. The sponsor still wants this car.

What I am asking is, the end objective within the set duration of time, in this case 1 month or less to deliver a  working car that meets the requirements of the sponsor hasn't changed. What we found out is that we underestimated the work in Sprint 1 and we had some things to complete for ex: painting the car. Therefore, this piece is incomplete from the overall product. Let us further assume that we learned from this experience and now we are absolutely confident that we will be able to finish this work in a week and we were successful.

Based on the above, can we really say that the work depreciated? Unless of course we introduce something like a competitor who was able to release before us and that resulted in us having to scrap the whole project or something along those lines.

Also, does this now make sense why I said work gets moved to the next Sprint instead of the backlog because it just has to be done.

If  I am wrong, I'd like to stand corrected.

Based on the above, can we really say that the work depreciated? 

Yes, because the investment made in the first Sprint did not return value until a subsequent Sprint. A Sprint’s worth of product usage and/or revenue was lost, along with the opportunity the team had to work on something else. A Product Owner ought to factor depreciation such as this into the total cost of product ownership.

If the Scrum Team crafts the Sprint Goal, why wouldn't the Scrum Team also be present to review a forecast that that cannot be met?

This goes to a fundamental belief that I have in the role of Scrum Master, or any agile coaching role. Individuals in such roles should generally be hands-off. Although there may be times when it's appropriate for a Scrum Master to be hands-on, I generally think that the Scrum Master should observe and offer feedback. For a less mature team, perhaps the Scrum Master will invite himself to all of the team's events to observe and offer feedback (perhaps unsolicited feedback). As the team matures, the events should be driven by other members of the team and the Scrum Master should need to be invited and feedback should be asked for, except for extreme circumstances.

Similarly, If the Sprint Goal is in danger of not being met, why would the active participant be the Product Owner and not the entire Scrum Team?

I did not say "the" active participant. The level of activity of the Product Owner changes depending on if the Sprint Goal will be met or not.

If the Sprint Goal will still be achieved without any changes to the associated Product Backlog Items in terms of scope or working agreements, then the Product Owner can simply be informed that some items won't be done, but there's a plan to accomplish the goal to the standards of the developing organization and team. However, if the Sprint Goal isn't going to be met, then the purpose of the Sprint will not be met and the intended value won't be delivered. Since the Product Owner is "responsible for maximizing the value of the product resulting from work of the Development Team", the Product Owner needs to be involved in understanding options, making decisions, and managing stakeholder expectations.

The key is that the valuable work is defined in the Sprint Goal. If there impacts to the value delivered, then the Product Owner must be involved.

I find Ian Mitchell's use of the word "commit" interesting, since it's not in the Scrum Guide. At one point, the team used to commit to completing the Sprint Backlog. Now, it's a forecast. But I do agree that there should be a team commitment to achieving the Sprint Goal. External to the Development Team, the Sprint Goal is the thing that is extremely highly visible and any work above and beyond that Sprint Goal is just that - above and beyond.

If the Product Backlog items forecasted to meet a Sprint Goal are the only ones in the Sprint Backlog, and if some of them are not met, can we still meet the Sprint Goal?

This is dangerous, and I know that there are other people here who agree with me since I've seen others write about this. If you consider your Sprint Goal a commitment, why would you put your entire capacity toward that commitment, with no buffer space? Consider that people (either your team or your team's families) get sick, personal obligations and family events, critical production issues, out-of-band meetings that may not be planned before the Sprint. Even if you calculate your capacity, it's a prediction and there's uncertainty. Treating your capacity as firm, fixed, and certain is a problem. This is a situation that should be avoided.

I find Ian Mitchell's use of the word "commit" interesting, since it's not in the Scrum Guide. At one point, the team used to commit to completing the Sprint Backlog. Now, it's a forecast. But I do agree that there should be a team commitment to achieving the Sprint Goal.

To be very specific, team members should commit personally to the Sprint Goal, along with any other goals the team might establish. This does not necessarily mean a commitment to the Sprint Backlog, which is a forecast of what needs to be done. It will however mean committing to do the work necessary for goal realization, acknowledging that much of that work could be emergent.

To be very specific, team members should commit personally to the Sprint Goal, along with any other goals the team might establish. This does not necessarily mean a commitment to the Sprint Backlog, which is a forecast of what needs to be done. It will however mean committing to do the work necessary for goal realization, acknowledging that much of that work could be emergent.

Yes - I may not have been clear, but this I fully agree with. I believe that commitment does have a place in Scrum, and commitment to the Sprint Goal is one of those. The Sprint Backlog is a forecast, which could change due to emerging work.

During a Sprint, a Development Team determines that it will not be able to finish the complete forecast. Who should be present to review and adjust the Sprint work selected?"

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

Answers:

A) The Scrum Master, the Product Owner and the Development Team.

B) The Product Owner and the Development Team.

C) The Product Owner and all stakeholders.

D) The Development Team.

I would argue B is the correct answer. The Scrum Master would only be present if requested by the Product Owner and/or the Development Team.

Here's my reasoning, if there is a review and adjust happening, isn't that a form of planning? If the Scrum Team is present during Planning, then why can't the Scrum Team be present here too? The Scrum Master's role would be to ensure that the changes are understood by all just as in Sprint Planning.

I agree that at a bare minimum the choice of B. is correct.

I am curious to know what others have to say about this and what their reasoning is if B. is indeed the right choice over A.

I'll chime in.  First, I have learned from this discussion and want to thank all of you for that. I just hope that my contribution can come close to the bar that has been set. 

I am curious to know what others have to say about this and what their reasoning is if B. is indeed the right choice over A.

If I was presented this question on an exam, I would choose B because technically it is right. Given the situation you presented I don't really see this as "planning". I see it more as "adjusting".  The team is not planning a Sprint, they are adjusting their plan to reflect reality.  As such, the Development Team and Product Owner have the most to gain or lose in whatever adjustments are decided upon. The Scrum Master is also responsible for the outcome of the Sprint but at this point their role will be to help remove further impediments and aid the rest of the team in making the situation and decisions visible to anyone outside of the team. So while B is technically right, I would hope that A is what actually occurs. 

First, I have learned from this discussion and want to thank all of you for that.

I second that. The discussion has evolved a bit towards and I don't really have much to add, but it has been incredibly insightful and wholesome. I'm happy to see that such a deceivingly simple question can lead to such deep considerations!

So while B is technically right, I would hope that A is what actually occurs. 

Note that A reads "The Scrum Master, the project manager and the Development Team.". If we swap out the PM for the PO, then maybe I get your point, but stated like this it would of course never be right answer to a PSM 1 or 2 question :)

During a Sprint, a Development Team determines that it will not be able to finish the complete forecast. Who should be present to review and adjust the Sprint work selected?"

If the forecast represents the work believed necessary to achieve the Sprint Goal, then only the Development Team and Product Owner have to be present. Since the Development Team has been able to determine that the forecast to meet the Goal cannot be met, this implies that the Goal is in fact understood by them.

The Scrum Master ought to attend if he or she considers the above implication to be false, because ensuring that goals are understood by the team is a service the SM owes to the Product Owner. The SM may also choose (or be requested) to attend for any number of other valid reasons.