Sprint Goal Queries

The Sprint Goal can be thought of as a commitment. The Development Team will agree to deliver an increment of functionality to the Product Owner, by the end of the Sprint, which meets that agreed Goal.

The Sprint Backlog is a forecast of the work that the team must do in order to meet the Goal. It is subject to replanning throughout the Sprint while the Goal itself does not change. It provides the flexibility needed to deliver an end-of-sprint increment that is fit for the agreed purpose.

For example, the team may discover that some of the items in the Sprint Backlog aren't needed to satisfy the Goal, or must be replaced with others. They may then replan the backlog accordingly so that the Sprint Goal can be better achieved.

Can you come up with your own example of a Sprint Goal which would support this flexibility?

Ok. So the flexibility here is wrt to what and different possibilities of the work / tasks to meet the objective

Let me try taking an eg from football. My sprint goal is to score a td in the first drive. My sprint backlog comprises of ground plays (ie run plays) to score a td but i see that one of their best secondary gets injured in a play, so i decide to go vertical to score a td. So i change my sprint backlog to replace the run play with throw but my sprint goal is intact ie to score a td.

Did i get it?

Hi ian,

I had a different query wrt sprint goal. Sprint goal is a commitment by the development team right? Lets say that during the sprint the team realizes that the work identified to meet the goal is more cumbersome than what they initially thought. So they negotiate the scope with the po. In this case wouldn't the goal of the sprint change as you might be removing a pbi altogether.

Hi

I had a similar doubt as that of @Venkat. Infact to quote from Scrum Guide

"During the Sprint:
No changes are made that would endanger the Sprint Goal;
Quality goals do not decrease; and,
Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned."

Now, isn't point no.1 and 3 are contradictory.

Thoughts?

A plan could change completely in order to meet a goal. Therefore *all* of the PBI's that were inducted into the Sprint Backlog could, at least in theory, be renegotiated during the Sprint in order to achieve the Sprint Goal.

Any undone work with respect to any inducted PBI's should be re-estimated. If those PBI's are no longer planned for completion in the current Sprint then they should remain on the Product Backlog for reprioritization and further refinement.

If the Sprint Goal appears to be unattainable regardless of how the Sprint Backlog is revised, then the best course of action may be to cancel the Sprint. This is a value-based decision which ought to be sanctioned by the Product Owner. The remainder of the Sprint timebox can then be replanned in order to deliver as much value as possible to the PO in whatever time is remaining.

So if renegotiating the scope leads to a situation where sprint goal cant be attained then canceling the sprint may be an optimal option, right?

But your last statement added one more query - if sprint is cancelled then wouldnt the scrum team get together for a new sprint planning where as the last statement says the remainder of the sprint timebox can be used to deliver as much value. So are you saying deliver something other than the sprint goal that was initially agreed?

> So if renegotiating the scope leads to a
> situation where sprint goal cant be attained
> then canceling the sprint may be an optimal option, right?

No. Scope should be renegotiated in order to make the Sprint Goal *more* achievable. If the Sprint Goal does not appear to be achievable at all, then the best option may be for the Product Owner to cancel the Sprint.

> But your last statement added one more
> query - if sprint is cancelled then wouldnt the
> scrum team get together for a new sprint
> planning where as the last statement says
> the remainder of the sprint timebox can be
> used to deliver as much value. So are you
> saying deliver something other than the
> sprint goal that was initially agreed?

They *might* start a new Sprint if that is the best way to deliver value to the Product Owner. However Sprint cadence would then be compromised. It could be better to make the most of the remaining timebox instead of starting a new one. This could be the case if there is an organizational release cadence to be respected, for example. In that situation the work of many teams may have to be integrated and various team events synchronized. In either case the objective should be to deliver maximum value to the PO.

Ok. So commitment to sprint goal is important but at the same time commitment to deliver value is paramount. Thanks.