Completion of work by the Development Team

A Sprint Goal will have been agreed with the Product Owner, who maximizes value for stakeholders and represents their interests, and Development Team members will have committed to achieving it.

A Sprint Goal will have been agreed with the Product Owner, who maximizes value for stakeholders and represents their interests, and Development Team members will have committed to achieving it.

Agreed, regarding the Sprint Goal, but does it mean that if, for example, more work emerges during the Sprint while implenting the backlog items, and as a result of which not everything gets completed, then does it mean that the Development Team was not committed? Also, in this example due to the emergence of work, does it mean they now have to deliver the functionality/work at any cost just because they committed to it during Sprint Planning? What if they were committed to finish but couldn't at the end of the Sprint?

I'm curious as to why stakeholders are looking at the Sprint Backlog. The Sprint Backlog is simply a representation of the work needed to achieve the Sprint Goal and a decomposition of the Product Backlog Items that were selected for the Sprint. Outside of the Scrum Team, I don't think that the Sprint Backlog is relevant for anyone since it's more technical and tactical. If there are concerns with achieving the Sprint Goal, then the Development Team should be raising these concerns to the Product Owner and the Scrum Team should be collaborating to determine what the right thing to do is and making sure there is clarity in what the Product Increment will look like at the end of the Sprint.

I'd also be concerned if large amounts of undiscovered work are emerging during the course of the Sprint. The team may not decompose all of the Product Backlog Items immediately, but if work is truly emerging, that would seem to imply that there has been insufficient effort in Product Backlog Refinement. Having a sufficiently refined set of Product Backlog Items in conjunction with a Sprint Goal is crucial for the negotiation between the Development Team and the Product Owner to determine what a suitable Sprint Goal is, since the goals and objectives of each Sprint are tied to communication between the Product Owner and other stakeholders.

Both of these topics would make for a great discussion at the Sprint Retrospective, with the entire Scrum Team.

I'm curious as to why stakeholders are looking at the Sprint Backlog. The Sprint Backlog is simply a representation of the work needed to achieve the Sprint Goal and a decomposition of the Product Backlog Items that were selected for the Sprint. Outside of the Scrum Team, I don't think that the Sprint Backlog is relevant for anyone since it's more technical and tactical.

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

@Thomas, Even though it belongs solely to the Development Team, why is it made highly visible? For whom? Who all may benefit from a highly visible Sprint Backlog?

If work keeps emerging during every Sprint and it becomes a pattern, then yes it needs to be investigated. However, my original question was to understand how to respond to an anxious stakeholder who thinks the work the Development Team has undertaken for the Sprint will not be completed. Should we advise him that no one tells the Development Team how to do its work and that we have to trust them to meet their committment of the Sprint Goal, or do we advise that the scope forecasted may not always be completed. Let us assume here that the stakeholder is anxious because he does not see progress and the Development Team hasn't communicated of any issues.

Whilst I feel the first option is the most apt, realistically, and I mean in real life, even though it may not be a constant affair, there are instances where there is incomplete work. An anxious stakeholder may expect that all work should be complete, and if it isn't they may blame the Development Team quoting they committed to completing it.

Agreed, regarding the Sprint Goal, but does it mean that if, for example, more work emerges during the Sprint while implenting the backlog items, and as a result of which not everything gets completed, then does it mean that the Development Team was not committed? Also, in this example due to the emergence of work, does it mean they now have to deliver the functionality/work at any cost just because they committed to it during Sprint Planning? What if they were committed to finish but couldn't at the end of the Sprint?

Development Team members can commit to whatever they like. If, for some reason, they commit to implementing a Sprint Backlog -- and subsequently fail -- then there is evidently a problem with the commitment being made. However, this would constitute a commitment to a forecast of work, rather than to the Sprint Goal. In Scrum, team members are expected to commit to the goals of the team.

There is no proscription against committing to a forecast (e.g. items on a backlog) or a part thereof, but it could perhaps be seen as being irregular. The items on a backlog, after all, are expected to change during a Sprint...while the Sprint Goal is not.

Development Team members can commit to whatever they like. If, for some reason, they commit to implementing a Sprint Backlog -- and subsequently fail -- then there is evidently a problem with the commitment being made. However, this would constitute a commitment to a forecast of work, rather than to the Sprint Goal. In Scrum, team members are expected to commit to the goals of the team.

Okay, so now I am clear that the commitment is to a forecast and not to the Sprint Goal, but how can anyone commit to a forecast (which is just an estimate/prediction) which has the potential to change? Here, I am assuming commit means absolutely, without fail, and not commit as in try our best.

@Steve, I interpreted @Ian's point differently.  If they team is committing to the forecast and not meeting the commitment, then attention should be turned to the team's ability to forecast.  If the team is committing to the Sprint Goal and not meeting the commitment, then attention should be turned to the Sprint Goals being crafted. 

I searched for the word "commit" in the Scrum Guide.  That word occurs 4 times and 2 of them as the root of "committee".  The only real reference to commitment was in the the section on Scrum Values.  This stood out to me:

People personally commit to achieving the goals of the Scrum Team. 

Sprint Goals are one of those goals and it is crafted specifically for each Sprint.  The Sprint Backlog is chosen to support the accomplishment of that goal.  Can the goal be accomplished without completing all the work chosen to be in the Sprint Backlog?  That is entirely up to the Scrum Team to decide as the Sprint goes along.  It is acceptable to modify the Sprint Backlog makeup in order to achieve the Sprint Goal as evident by this passage in the section on Sprint Planning (emphasis added by me):

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

The Scrum Guide was changed in 2011 to remove the concept of Sprint Commitment and replaced with Forecast. From what I know of the reason for change was because of the misunderstanding derived from the "commitment".  That misunderstanding was very much like this statement made by you.

Here, I am assuming commit means absolutely, without fail, and not commit as in try our best.

Failure is only a true failure if nothing is learned from the situation. If you fail to meet your goal, can learn why and adapt for the future behavior for those consequences, then you are being truly agile. Only if you fail to inspect and adapt are you truly failing.  I have a saying that I use over and over again. "The only mistake is one from which you don't learn."  I'm sure I stole that from someone but I still feel it to be true.  In fact a quick google found this page of quotes on failure.  And not a one of the quotes says failure is bad.

https://awakenthegreatnesswithin.com/35-inspirational-quotes-on-failure/

The Scrum Guide was changed in 2011 to remove the concept of Sprint Commitment and replaced with Forecast. From what I know of the reason for change was because of the misunderstanding derived from the "commitment".  That misunderstanding was very much like this statement made by you.

@Dan, The changes you mentioned above was one of the reasons why I asked this question because if commit is removed and replaced with forecast, and if forecast is only a prediction, then there is no guarantee that the team will complete all the work, if such a situation arises. However, I am not saying that the team isn't committed to its work. In fact, I am supportive of this change. 

Keeping the above points regarding commit and forecast in mind along with the fact that work can emerge during the Sprint from the Sprint Backlog, for the question I asked, I am just trying to get clarity on how to respond to the stakeholder and to understand if both the options are right. 

Let me see if I can clarify this with how I would handle a request. If a project team, asks me if my Development Team can deliver some functionality by a certain date, I would always first consult with my team and then respond, it looks doable by that date (forecast) but this is assuming we don't run into any issues that may delay this. Therefore, we commit to this forecast but we also set expectations. 

@Steve, I believe your approach is valid.  But I have to ask if you are the Product Owner or the Scrum Master.  Because the Product Owner is the one that usually is expected to provide likely delivery dates based on progress to date.  This comes from the Guide's section on the Product Backlog.

At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.

Various projective practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.

As Scrum Master I would be referring anyone asking me those questions to the Product Owner.  I would do everything I can to help the PO make the determinations but ultimately it is up to the Product Owner to make the decisions on what is to be done for a Product.  The making all information visible to anyone gives everyone the ability to see what is in progress.  The PO can then interpret for the benefit of external parties.

Okay, so now I am clear that the commitment is to a forecast and not to the Sprint Goal, but how can anyone commit to a forecast (which is just an estimate/prediction) which has the potential to change? Here, I am assuming commit means absolutely, without fail, and not commit as in try our best.

Generally they can’t. That’s why I said: “in Scrum, team members are expected to commit to the goals of the team”. The Sprint Goal is one of these, and it does not change. 

Team members can commit to whatever they like. However a forecast like a Sprint Backlog is unlikely to represent a commitment, since it is mutable.

if commit is removed and replaced with forecast, and if forecast is only a prediction, then there is no guarantee that the team will complete all the work...



If a project team, asks me if my Development Team can deliver some functionality by a certain date, I would always first consult with my team and then respond, it looks doable by that date (forecast) but this is assuming we don't run into any issues that may delay this. 

Steve, in regards to the first part, there is never a "guarantee" that a team can complete all of their work, whether they communicate this via commitment or forecast.

For the second statement, have you tried doing any Monte Carlo analysis around your forecasts?   You can take historical data and use it to provide a % likelihood of an outcome, such as a forecast being met.