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?
Not delivering something means the sprint was less successful than it was forecast to be. It doesn't mean the sprint needs to be cancelled. The increment should be "potentially releasable" but the decision on whether to release or not ought to be taken at the end of the sprint and then the incomplete stories can be considered for the next sprint alongside other priorities. Those kind of situations often arise but the team should learn something from them so that they are better able to forecast the next sprint. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
I can write a lot on this because it is a typical situation. But my piece of advice is take a closer look to Mike Cohn book "Agile Estimating and Planning" or go to Mike´s website and blog and you will find the same answers but extended. But my recommendation is: one of the classical fails is to wait when things happend instead of to antcipate it. One of the reasons to have daily scrums is becasue of that, not because doing micromanagement (other of the classical mistakes). People has to take into account that a user story is not a requirement in the sense that something can be constructed with the user story, is an invitation to talk to get more information then clarify the user story to create a requirement. Because of that, in the time the user story is clarified people is able to understand if the estimated can be achieved. Take a look to Barry Boehm´s Cone of Uncertainty
...
1 reply by Mohit Joshi
Aug 04, 2020 7:34 PM
Mohit Joshi
...
Thanks Sergio. I did read Mike's blog on this topic. It is very helpful but it focuses on what actions are appropriate should the situation arise. Not much on whether it is acceptable to have a Sprint where not all planned items are completed (and would it still be called as a successful value add since the increment may not be releasable)?
I learn that it is typical to have a Sprint with incomplete items and ways to handle that (retrospect on root cause, split the story points or move the item to next appropriate Sprint). But is it okay to have that incomplete Sprint where not all planned items met DoD? Or it is better to cancel the Sprint before the time-box since the goal may not be completely achieved (again goal may not be achieved, not that it becomes obsolete).
I can write a lot on this because it is a typical situation. But my piece of advice is take a closer look to Mike Cohn book "Agile Estimating and Planning" or go to Mike´s website and blog and you will find the same answers but extended. But my recommendation is: one of the classical fails is to wait when things happend instead of to antcipate it. One of the reasons to have daily scrums is becasue of that, not because doing micromanagement (other of the classical mistakes). People has to take into account that a user story is not a requirement in the sense that something can be constructed with the user story, is an invitation to talk to get more information then clarify the user story to create a requirement. Because of that, in the time the user story is clarified people is able to understand if the estimated can be achieved. Take a look to Barry Boehm´s Cone of Uncertainty
Thanks Sergio. I did read Mike's blog on this topic. It is very helpful but it focuses on what actions are appropriate should the situation arise. Not much on whether it is acceptable to have a Sprint where not all planned items are completed (and would it still be called as a successful value add since the increment may not be releasable)?
I learn that it is typical to have a Sprint with incomplete items and ways to handle that (retrospect on root cause, split the story points or move the item to next appropriate Sprint). But is it okay to have that incomplete Sprint where not all planned items met DoD? Or it is better to cancel the Sprint before the time-box since the goal may not be completely achieved (again goal may not be achieved, not that it becomes obsolete). Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Its hard to answer because the decision depends on several factors. I will answer what worked for me most of the times and speaking with a degree of generalization. Sprint must not be cancelled. I fact, you will find, mainly when you start working with Scrum, that you will get some type of "accurancy" about planned vs actual after you run 3 sprints. The point here is, between other things, the method you use to estimate. The worst case is to use story points. Why? Because each method has an inherent error which is related to the amount of information you have to estimate but story points is the method which the highest impact/error because the method itself. So, perhaps I did not answer your question (let me know) but the summary of this history is you will get work not done for each sprint until you get more expertise on working with this way of work and behave. The important thing is what you learn from having work not done. Saving Changes...
The intention of my question is 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 overall targeted 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). 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 reply by David Portas
Aug 05, 2020 1:24 AM
David Portas
...
1. Acceptable? The situation you describe is undesirable but people accept that these things happen. Sprints are short and the point is that sprints are an indefinitely continuing cycle. Not every sprint has to result in a release and nothing you have said suggest that a sprint should be "cancelled" (whatever that means in your case).
2. The DoD should define the completion of *stories*. If some stories are complete then they shouldn't need to be reprioritised: just add the incomplete stories to another sprint.
The intention of my question is 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 overall targeted 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). 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. Acceptable? The situation you describe is undesirable but people accept that these things happen. Sprints are short and the point is that sprints are an indefinitely continuing cycle. Not every sprint has to result in a release and nothing you have said suggest that a sprint should be "cancelled" (whatever that means in your case).
2. The DoD should define the completion of *stories*. If some stories are complete then they shouldn't need to be reprioritised: just add the incomplete stories to another sprint. Saving Changes...
Sprint cancellation is a traumatic, exceptional event and is definitely not done just because the team couldn't complete all sprint backlog items. Remember that the sprint backlog is a forecast which means that some items may not be complete for a variety of reasons.
As far as the implication of incomplete or not started backlog items on the PSPI or an upcoming release, that really depends on the decisions made by the PO and other stakeholders. If there is sufficient value in releasing what has been completed then they may choose to do so.
Kiron
...
1 reply by Mohit Joshi
Aug 05, 2020 11:26 AM
Mohit Joshi
...
Thanks Kiron and David.
I learn that it is possible to have a sprint where the team may not be able to complete all forecast backlog items. And if that does happen, the PO (along with other stakeholders) will make the call whether the completed sub-set of items add value to the increment or not - and choose to release them.
- If the completed items (say 7 out of planned 10 backlog items) add value to the increment, they may be accepted. The remaining 3 would be moved back to PB & re-prioritized in a subsequent sprint.
- If the completed items doesn't add value to the increment, the entire set (of 10 items) may be moved back to PB & re-prioritized in a subsequent sprint (even though only 3 items remains to be done). Is this correct? Or even in this case only the remaining items are moved back to PB for re-prioritization.
At the end, all depends on what value the completed items bring to the increment.
Sprint cancellation is a traumatic, exceptional event and is definitely not done just because the team couldn't complete all sprint backlog items. Remember that the sprint backlog is a forecast which means that some items may not be complete for a variety of reasons.
As far as the implication of incomplete or not started backlog items on the PSPI or an upcoming release, that really depends on the decisions made by the PO and other stakeholders. If there is sufficient value in releasing what has been completed then they may choose to do so.
Kiron
Thanks Kiron and David.
I learn that it is possible to have a sprint where the team may not be able to complete all forecast backlog items. And if that does happen, the PO (along with other stakeholders) will make the call whether the completed sub-set of items add value to the increment or not - and choose to release them.
- If the completed items (say 7 out of planned 10 backlog items) add value to the increment, they may be accepted. The remaining 3 would be moved back to PB & re-prioritized in a subsequent sprint.
- If the completed items doesn't add value to the increment, the entire set (of 10 items) may be moved back to PB & re-prioritized in a subsequent sprint (even though only 3 items remains to be done). Is this correct? Or even in this case only the remaining items are moved back to PB for re-prioritization.
At the end, all depends on what value the completed items bring to the increment.
Completed work items should never get moved back to the product backlog - if they are done, then they are part of the product to be released at some future point in time.
Kiron
...
1 reply by Mohit Joshi
Aug 05, 2020 12:07 PM
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.
Completed work items should never get moved back to the product backlog - if they are done, then they are part of the product to be released at some future point in time.
Kiron
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.
...
1 reply by Kiron Bondale
Aug 05, 2020 4:55 PM
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...
