Kill the Sprint

Gourab,

What does the Scrum Guide say regarding the following:

1) What are reason(s) for terminating a sprint?

2) Who has authority to terminate a sprint?


Based on these answers, how would you manage the above scenario?

Hi Timothy,

A Sprint would be cancelled if the Sprint Goal becomes obsolete.
This might occur if the company changes direction or if market or technology conditions change.
In general, a Sprint should be cancelled if it no longer makes sense given the circumstances.

This i understood but my question remains unanswered...

If the Dev Team has taken up 5 PBIs for the sprint.
Towards the end of the sprint due to some blocker or dependency with other system or some Technical challenge one the PBI not completed on time.

So does this mean to kill the Sprint just because of one PBI was not completed??

Thanks

Gourab,

Is the PBI still valid for the company even if it is not finished in the sprint?

Can the Sprint Goal still be achieved without the unfinished PBI (assuming the other 4 are completed)?

So does this mean to kill the Sprint just because of one PBI was not completed??

What do you think?

Hi Timothy,

To answer your queries..

Is the PBI still valid for the company even if it is not finished in the sprint? - YES

Can the Sprint Goal still be achieved without the unfinished PBI (assuming the other 4 are completed)?

Sprint Goal was set with the 5 PBI to complete. 4 finished but 1 not.Ideally sprint Goal was not achieved.But my question lies here is it possbile to finish the sprint with 4 completed PBIs ???

If YES - what needs to be done with the unfinished PBI?

If NO - Does it mean to kill the sprint just bcz of 1 unfinished PBI??

Thanks,

Hi Gourab,

Nice to see you on the forums. Sometimes, we don't get direct answers, but people are well-meaning when responding.

.
.
.
.

So does this mean to kill the Sprint just because of one PBI was not completed??

A Sprint is not "killed." There is either a sprint cancelled (abnormal termination of the Sprint) or the timebox expires. I'm having a slightly hard time reading your question as 2 scenarios come to mind.

A) The timebox is over and it is time to go for the Sprint Review
- If such, this just happens and unfinished work is reassessed and returned to the product backlog. From what I have seen, usually, this goes up high on the product backlog and the Team takes it in the subsequent Sprint.

B) There are still a few days remaining before the start of the Sprint Review
- What happens here is situational and is different for various Teams. While certainly a retrospective item here are a few thoughts.
-- A Product Owner, having ordered the backlog may have something that the Dev Team can continue working on. To keep the cadence, the Dev Team may pick something else.
-- Or, the PO may cancel the Sprint.

Some added clarity on your scenario will help.

Hi Nitin,

Thanks for your reply..

A) The timebox is over and it is time to go for the Sprint Review
- If such, this just happens and unfinished work is reassessed and returned to the product backlog. From what I have seen, usually, this goes up high on the product backlog and the Team takes it in the subsequent Sprint.

so something is unfinished and timebox for sprint got over, then we can return the work item back to product backlog . so what will be the status of this backlog item, as this has been taken in the sprint work item status will be Approved.Now as we are returning back this item to product backlog with high priority the work item status will be new or Ready to Groom again????

B) There are still a few days remaining before the start of the Sprint Review
- What happens here is situational and is different for various Teams. While certainly a retrospective item here are a few thoughts.
-- A Product Owner, having ordered the backlog may have something that the Dev Team can continue working on. To keep the cadence, the Dev Team may pick something else.
-- Or, the PO may cancel the Sprint.

PO may cancel the sprint just bcz 1 item can not be completed ??? i know the decision lies on PO only.

Thanks,
Gourab

I often find that everything in Scrum has a domino effect.

so what will be the status of this backlog item, as this has been taken in the sprint work item status will be Approved.Now as we are returning back this item to product backlog with high priority the work item status will be new or Ready to Groom again????

[Via NK] -- It depends.

-- If other information has emerged or the Team has learned something new, there can be refinement. (Minor note: the word "grooming" was replaced in the Scrum Guide.) Some Teams may have formally defined "Ready" and what that means? It is also acceptable to discuss this during the next Sprint Planning.
-- OR If everyone is aligned it is simply a familiar product backlog item
-- OR the item may not be "ready" as there is a clear dependency / impediment around this
-- OR the item may now be obsolete (rare)

.
.
.

PO may cancel the sprint just bcz 1 item can not be completed ??? i know the decision lies on PO only.

[Via NK] -- Yes.

Hope that some of this helps you, as well as others following this thread.

So does this mean to kill the Sprint just because of one PBI was not completed??

No.

The reasons for terminating a sprint are listed in the Scrum Guide. Failing to complete one PBI, or determining that one PBI no longer applies to the Sprint Goal, is insufficient for Sprint Termination consideration.

This is a lot of hand-wringing over an exception scenario that many will never encounter.

Remember that you can have a successful Sprint even if *none* of the originally planned PBI's are delivered. Not even one.

This is because the Sprint Backlog represents a *forecast* of the work needed to meet the Sprint Goal...and it is the Goal, not the forecast, which represents the team's commitment.

Indeed, Ian is right. Successful Sprint should be closely associated with the Sprint Goal, but often teams associate the Sprint Goal in very simplistic terms just saying we will complete all X number of PBI's in this Sprint. This is plain wrong and a missed opportunity to describe the Sprint goal in terms of value and cohesion of the increment that has to meet the DoD. and potentially releasable. 

Wow, I take a break for a few weeks and really miss out! Since the issue of cancelling the sprint was already taken care of, I would really like to call out a serious flaw I noticed from the OP's comments.

Sprint Goal was set with the 5 PBI to complete. 4 finished but 1 not.Ideally sprint Goal was not achieved.But my question lies here is it possbile to finish the sprint with 4 completed PBIs ???

I think you have some confusion on what the Sprint Goal is. The Sprint Goal is not the number of items you hope to complete; as in this case the Sprint Goal is NOT to complete 5 PBIs.

Instead, the Sprint Goal (in short) is a summarization of the increment you're working to create during the sprint. If you use the Sprint Goal as simply being the number of PBIs that the team hopes to finish, you're not really working towards an increment; you're just working on random bits and pieces. Back to the initial question of whether the Sprint should be cancelled because of 1 PBI not being completed; that depends on the item. In most cases, it won't be necessary to cancel the sprint; but in some cases you will find that the sprint goal can become obsolete because of 1 PBI.