Handling Incomplete Work during Sprint

Now, if the situation arises that the dev team couldn't complete the planned work in a Sprint (due to reason/delay beyond control, skill gap etc.), how is it decided whether the Sprint resulted in value add or should be cancelled (can it be cancelled even with 1 or 2 days left in the time-box)? What if the items that couldn't be completed were required to make an increment releasable?

@Mohit Joshi, One important thing I didn't see here is asking the question "Did we meet the Sprint Goal?". Every Sprint is undertaken with something to be accomplished, so did you accomplish that? If you didn't what do you need to do? What learnings did you get that you can ensure you meet your objective the next Sprint? Since you mentioned skill gap, did you factor in if you could create a potentially releasable Increment that meets the Definition of "Done"? The Sprint Goal and DoD are two things that you could use to ensure successful outcomes.

For example: if the dev team planned to finish 10 user stories but could finish only 6. Now during sprint planning it was decided that completing those 10 stories would make up for a value add & increment version of the product that can be potentially releasable. Failing to do the remaining 4 stories would mean, we have a resultant increment that is not releasable. So, does that mean the Sprint was unsuccessful? Or what is the recommendation to handle that? Do we just re-estimate the pending work, re-prioritize it & focus on next Sprint planning?

Here, again, are the 10 PBI's aligned to a Sprint Goal or just 10 PBIs?

Thanks Steve for the response. Yes, the 10 PBIs are aligned to the Sprint goal that is defined during Sprint Planning.

However, there could be occasions where the dev team is unable to complete all of them. One recommendation as per the guide is re-negotiate the items with PO during the Sprint but it may not always be possible to do so (keeping the goal & definition of done in mind). Removing the items from the current sprint would only be the option since they can't be completed.

Is that okay to miss the goal for a Sprint or produce an increment that is not releasable? The lessons learnt can surely be discussed in the retrospective & improvements can be worked on but the resulting increment would not be as expected per DoD...

Here the goal is not obsolete but missed, so cancellation might not be ideal. What is the recommendation to address this and should the stakeholders be prepared that this can occur (before the Sprint Review)?

Yes, the 10 PBIs are aligned to the Sprint goal that is defined during Sprint Planning.

Good. Is this then a one-time situation or a recurring pattern? Was the Sprint Goal something that could have been achieved, based on information that was known at the time of Sprint Planning?

Is that okay to miss the goal for a Sprint or produce an increment that is not releasable? The lessons learnt can surely be discussed in the retrospective & improvements can be worked on but the resulting increment would not be as expected per DoD...

Being unable to achieve the Sprint Goal is an opportunity to Inspect why, and Adapt. The goal of a Sprint is to produce a potentially releasable Increment. Also, a Done Increment is required at the Sprint Review. If you were unable to meet the goal, then why this happened and what problems the DT ran into can be made transparent and discussed with the stakeholders.

Hope this helps.

Thank you Steve. It does help.

The intention of my question was to learn more on below two things:

1. Is it acceptable to have a Sprint with incomplete items that may (internally) result in an increment that is not potentially releasable yet?

2. If that does occur, will the completed items be still accepted if they don't make the functionality releasable? Or would the entire Sprint be declared not meeting the DoD?

It's a little tricky to put it in an example but let me try: 

Say the team is trying to achieve Sprint goal A -> for that there are 10 user stories picked from PB post alignment with PO & planned in the Sprint (that would make functionality A ready for release). But if the team could complete only 7 user stories by end of the Sprint, the result would be not a ready feature A. Would the 7 stories be still acceptable or should the entire feature be re-prioritized & moved to a subsequent Sprint, even though only 3 stories remain?

1. Is it acceptable to have a Sprint with incomplete items that may (internally) result in an increment that is not potentially releasable yet?

2. If that does occur, will the completed items be still accepted if they don't make the functionality releasable? Or would the entire Sprint be declared not meeting the DoD?

The short answer to both the questions is Yes.

Say the team is trying to achieve Sprint goal A -> for that there are 10 user stories picked from PB post alignment with PO & planned in the Sprint (that would make functionality A ready for release). But if the team could complete only 7 user stories by end of the Sprint, the result would be not a ready feature A. Would the 7 stories be still acceptable or should the entire feature be re-prioritized & moved to a subsequent Sprint, even though only 3 stories remain?

Based on the info, I am assuming that your Scrum Team was not able to meet the Sprint Goal. Now, the 7 PBI's, can they be considered potentially releasable? i.e. can it be added to the existing Increment and it won't cause the existing Increment to become unstable, and the work is fully tested. If yes, then yes, then the PO can accept that work. If not, then the question is, is it still important? What follows next is based on what is relevant to pursue in the subsequent Sprint based on what your Scrum Team has learnt by undertaking the previous Sprint.

Hope that provides sufficient clarity.

2. If that does occur, will the completed items be still accepted if they don't make the functionality releasable? Or would the entire Sprint be declared not meeting the DoD?

A slight correction as I read this question incorrectly.

The completed items can be accepted provided it can be added to the existing Increment and it won't cause the existing Increment to become unstable, and the work is fully tested. The Sprint is not declared not meeting the DoD, the DoD is for checking the Done-ness of the Increment.

Thanks Steve. Appreciate the inputs.

I do not believe that a Sprint should be canceled if the Development Team cannot complete the planned work.

The Scrum Guide states that Sprint cancellation happens "if the Sprint Goal becomes obsolete", giving examples such as when a company changes direction or when market conditions change. It also notes that "due to the short duration of Sprints, cancellation rarely makes sense".

The team also doesn't commit to completing work during a Sprint. The team forecasts the work that they can complete within the timebox, but there's an acknowledgment that there's still some level of unknown that may prevent the full scope of work from being completed.

Practically speaking, I would suggest that achieving a Sprint Goal should not require completing all Product Backlog Items selected for a Sprint. This is effectively demanding that your plan be perfect, which we know is extremely difficult. Unless a team has sufficient information to make a more informed decision, I recommend that achieving a Sprint Goal should be achievable with about 70% of the team's projected capacity.

I would also suggest that if the failure to complete one or more selected Product Backlog Items led to an increment that is not potentially releasable, the Product Backlog Items are not sufficiently independent. There's a distinction between "potentially releasable" and being releasable or deliverable. Scrum calls for a potentially releasable product at least once per Sprint (and it doesn't have to be at the end, either), which can be reviewed at the Sprint Review. However, even if it is potentially releasable, the cost of actually releasing or delivering it may be higher than the value that it adds, so it would not necessarily be released as part of that Sprint.

Incomplete work is placed back on the Product Backlog, where the PO decides what to do with it.

Thanks Thomas and Sander.

So, if there are 10 forecast backlog items in a sprint (and completing them all will make a feature done & valuable), but the team was able to complete only 6 out of them due to various reasons, what I understand is below:

- if the completed 6 items still add value to the existing increment, the PO would accept it. The remaining 4 items would be moved back to the PB and re-prioritized in subsequent sprint (may not be next).

- if the completed 6 items doesn't add value to the existing increment, the entire set of 10 items would be moved back to PB and re-prioritized for a subsequent sprint (even though only 4 items remains). 

Is this correct understanding?

-- Mohit

If Scrum could be reduced to one purpose only, it would be the creation of "Done" increments of working product. Having a Sprint Goal to aim for facilitates the act of value creation by giving team members a reason to work together.

At any given moment, the Product Backlog ought to express how much work is currently thought to remain.

I don't think the understanding is correct.

The Product Owner, on behalf of the stakeholders, accepts the Increment and decides what to do with it, typically either "release" or "don't release", depending on the cost of releasing and the value that would be added since the last release. As part of the Sprint Review, the stakeholders should be able to review the 6 items that were done, provide feedback on them, and reorder the Product Backlog based on the current state of the world. This could be requesting refinements to the "done" work, changing the order of the undone work, or even removing things that they learn really weren't necessary after all. The items that were done would never be moved back into the Product Backlog since the Product Backlog is "an ordered list of everything that is known to be needed in the product" - done work is not needed in the product.

I'm not sure what type of product you are making, but in the software world, we can use dark launching, feature toggles, and keystone interfaces in order to continually provide a potentially releasable increment. That is, each individual piece of Done work can be integrated into the Increment and the Increment can, if desired, be released on a regular (perhaps even continuous) basis. We can enable the feature toggle or put in the keystone interface in test and demonstration environments to receive feedback on the pieces that are done, while hiding the pieces that form an incomplete or not-yet-sufficiently-done feature in our live production environments. Other domains may have other ways of solving this problem, but the intent is to get rapid feedback on the changes from stakeholders.

Okay, I guess I was looking from the perspective of backlog items completion rather than what value each done item would bring in. Changing that perspective would make more sense (value based delivery).

The development  team always try their best to forecast how much backlog items they can handle in a sprint (based on the prioritized PB). And there is a certain goal to achieve.

Now, due to certain reasons, if they are unable to complete all the forecast items, three things could happen:

1. The PO evaluates if the completed items bring any value addition to the existing product increment (or make the existing increment unstable). Based on that, he/she may release the items to seek feedback.

2. Re-prioritize the remaining backlog items and plan if they should be included in the next sprint or a future one. Only the remaining items are moved back to Product Backlog.

3. Retrospective should occur on why the dev team couldn't complete what was planned in the current sprint and ways to improve that/resolve any impediments for future sprints. Maybe the user story needs a split.

Appreciate the inputs and the information everyone.

Thanks,

Mohit

Thanks Steve for the response. Yes, the 10 PBIs are aligned to the Sprint goal that is defined during Sprint Planning.

However, there could be occasions where the dev team is unable to complete all of them. One recommendation as per the guide is re-negotiate the items with PO during the Sprint but it may not always be possible to do so (keeping the goal & definition of done in mind). Removing the items from the current sprint would only be the option since they can't be completed.

The goal isn't to "do work".

the goal is: I made sure the customer could drive their car.

Your plan might be 

I took their phone call

I towed their car

I insepected their car

I fixed their car

but on the night, your truck driver sees them broken down - you didn't take their call, you didn't inspect their car, you didn't tow their car - you just fixed their car.

you only did 1 PBI. But you achieved the goal.

The plan was not followed but the goal was met.

You should always be looking to maximise work not done while still achieving the goal.