Project Management

Please login or join to subscribe to this thread

Handling Incomplete Work in Scrum

linkedin twitter facebook  
avatar
Mohit Joshi Germantown, Tn, United States
Hello,

I have a question regarding incomplete work during a Sprint.

While it is mentioned in the Scrum guide (in the context of Sprint cancellation) that -

"All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated."

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?

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?

Thanks,
Mohit
Sort By:
< 1 2 >
avatar
Kiron Bondale Retired | Mentor| Retired Welland, Ontario, Canada
Aug 05, 2020 12:07 PM
Replying to Mohit Joshi
...
Hmm...interesting. So if there are items that are complete in the current sprint but don't add value to a functionality since there are dependent items yet to be completed (in a subsequent sprint), they are still marked as complete in the current sprint & accepted by PO. Only when the remaining dependent items get complete and they can add value to the increment, the PO may choose to release them.

The differentiation is between "acceptable" and "potentially releasable". Any completed backlog items may be accepted as long as it meets the definition of done but only when it adds value to the existing increment, the PO may choose to release them.

Hope I captured that right.
There may be a variety of reasons that a release happens including it is just scheduled to happen at regular intervals and whatever is done gets included. The PO determining when to do a release is just one possible approach.

I'm not a fan of work items being completed in reverse order when it comes to dependencies as you end up building "inventory" which could become stale and need to be reworked once the dependent work items get completed. Dependencies need to be considered when prioritizing the backlog...

Kiron
...
1 reply by Mohit Joshi
Aug 05, 2020 5:45 PM
Mohit Joshi
...
Agreed Kiron. Dependencies must be considered while prioritizing backlog items.

Suppose that is done and the team couldn't complete all planned dependent items in the current sprint - what is the recommended action in this case? Are the completed items accepted while the remaining re-prioritized for subsequent sprint or they all are moved to subsequent sprint & only when all are done, they are considered as complete/done (and part of that sprint where the remaining backlog items are completed)?
avatar
Mohit Joshi Germantown, Tn, United States
Aug 05, 2020 4:55 PM
Replying to Kiron Bondale
...
There may be a variety of reasons that a release happens including it is just scheduled to happen at regular intervals and whatever is done gets included. The PO determining when to do a release is just one possible approach.

I'm not a fan of work items being completed in reverse order when it comes to dependencies as you end up building "inventory" which could become stale and need to be reworked once the dependent work items get completed. Dependencies need to be considered when prioritizing the backlog...

Kiron
Agreed Kiron. Dependencies must be considered while prioritizing backlog items.

Suppose that is done and the team couldn't complete all planned dependent items in the current sprint - what is the recommended action in this case? Are the completed items accepted while the remaining re-prioritized for subsequent sprint or they all are moved to subsequent sprint & only when all are done, they are considered as complete/done (and part of that sprint where the remaining backlog items are completed)?
avatar
Mohit Joshi Germantown, Tn, United States
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 (PB is the source showing how much work remains - hence completed items are not moved to PB even if dependency exists).

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.
...
2 replies by Adrian Carlogea and Sergio Luis Conte
Aug 05, 2020 7:15 PM
Sergio Luis Conte
...
If you are used Kanban to monitoring and control what happend along the generation of the product then take a closer look about the basement of Kanban:
1.After you create each column pay attention that you need rules to move one item to the next column. The rule is the limit for each column. If you reach the limit then a new item must not be added to the column until other item is pull out of the column.
2.WIP has to be calculated taken into account VA and NVA items. WIP will determine the efficience of your Kanban.
This simple things are mostly forgotten but it helps to deal with backlogs but just in case you are using Kanban.
In all you stated above I guess is something missing: the difference between product backlog and sprint backlog. When a item can not be completed into a sprint it will be part of the next sprint backlog if apply. I guess you are using both things as a synonim and they are not the same.
Aug 05, 2020 9:47 PM
Adrian Carlogea
...
"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. "

It is for things like this that many software developers hate Scrum and any other things that claim to be "Agile".

Software development is to a reasonable degree some sort of art. You can't accurately estimate how long a task would take and as such you can't find out why the estimates were not correct.

Software development is not not like digging a trench. It is an activity that requires a good degree of creativity.

I understand that there may also be some non-technical reasons for missing dead-lines but you can't accurately estimate a creative work.

If you ask a developer why he hasn't completed the work in the estimated time (assuming he estimated the time himself) he would just give you a very deep technical explanation of the work he is doing and would go through all the code he has written so far and would explain to you all his technical difficulties. If you are not a developer yourself the you would understand nothing.

There is absolutely nothing wrong if the developers don't finish tasks in the time they estimated. The only thing you can do to fix this is to add more time to his estimates. :)
avatar
Sergio Luis Conte Helping to create solutions for everyone| Worldwide based Organizations Buenos Aires, Argentina
Aug 05, 2020 6:56 PM
Replying to Mohit Joshi
...
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 (PB is the source showing how much work remains - hence completed items are not moved to PB even if dependency exists).

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.
If you are used Kanban to monitoring and control what happend along the generation of the product then take a closer look about the basement of Kanban:
1.After you create each column pay attention that you need rules to move one item to the next column. The rule is the limit for each column. If you reach the limit then a new item must not be added to the column until other item is pull out of the column.
2.WIP has to be calculated taken into account VA and NVA items. WIP will determine the efficience of your Kanban.
This simple things are mostly forgotten but it helps to deal with backlogs but just in case you are using Kanban.
In all you stated above I guess is something missing: the difference between product backlog and sprint backlog. When a item can not be completed into a sprint it will be part of the next sprint backlog if apply. I guess you are using both things as a synonim and they are not the same.
avatar
Adrian Carlogea Australia
Aug 05, 2020 6:56 PM
Replying to Mohit Joshi
...
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 (PB is the source showing how much work remains - hence completed items are not moved to PB even if dependency exists).

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

It is for things like this that many software developers hate Scrum and any other things that claim to be "Agile".

Software development is to a reasonable degree some sort of art. You can't accurately estimate how long a task would take and as such you can't find out why the estimates were not correct.

Software development is not not like digging a trench. It is an activity that requires a good degree of creativity.

I understand that there may also be some non-technical reasons for missing dead-lines but you can't accurately estimate a creative work.

If you ask a developer why he hasn't completed the work in the estimated time (assuming he estimated the time himself) he would just give you a very deep technical explanation of the work he is doing and would go through all the code he has written so far and would explain to you all his technical difficulties. If you are not a developer yourself the you would understand nothing.

There is absolutely nothing wrong if the developers don't finish tasks in the time they estimated. The only thing you can do to fix this is to add more time to his estimates. :)
< 1 2 >

Please login or join to reply

Content ID:
ADVERTISEMENTS

"If you think you can, you can. And if you think you can't, you're right."

- Mary Kay Ash

ADVERTISEMENT

Sponsors







Vendor Events

See all Vendor Events

Newsletters

Jun 3: The Career Problem Facing New PMs
May 20: Your PM Career as a Project Life Cycle
May 13: The Big Lie After Layoffs

See all newsletters