Sprint Goal Queries

Last post 10:12 pm June 29, 2015
by Venkataraman Balasubramanian
8 replies
Author
Messages
02:03 am June 28, 2015

Hi,

Appreciate help in understanding the below statements from the guide -

"Sprint goal gives the development team some flexibility regarding the functionality implemented within the sprint."

is this referring to the tools and technology flexibility (ie an aspect of self organization). if so then wouldn't that flexibility stay even in the absence of the sprint goal? can somebody explain this with an example? thanks.

03:10 am June 28, 2015

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?

10:28 pm June 28, 2015

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?

10:42 pm June 28, 2015

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.

11:34 pm June 28, 2015

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?

02:58 am June 29, 2015

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.

11:18 am June 29, 2015

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?

02:35 pm June 29, 2015

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

10:12 pm June 29, 2015

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