Incomplete Tasks within a sprint - Move back to product backlog?

If you pick the second option, what is the value of your incomplete task?

Either approach may be valid depending upon the nature of the Product Backlog Item:

• If the PBI is an actual specification then your first option may be appropriate.
• If the PBI is a user story, and thus a placeholder for a conversation, then the second approach may be better, since the conversation planned for the Sprint is then over.

Remember that, in truth, a PBI does not "leave" the Product Backlog when it is planned into a Sprint Backlog. In-progress work is still yet to be completed, and a well-formed Product Backlog will include it until such time as it is incorporated into a Done increment. The question you are asking is a common one, and is often prompted by tool behaviors and constraints which can fog this issue. 

Thanks guys for the input....

@Clem Conti - Actually the decision was to go with option 1 for now, we did not go with option 1, however if I were to give a pros on option 2, it would be merely on keeping history of what has been accomplished within that sprint, which we ended up not achieving our DoD, but some effort was put into user story / tasks.

@ Ian Mitchell - In this case, the user story is an actual specification, and not a placeholder. For now we ended up going with option 1, but honestly, its a tricky situation, as I don't see right or wrong here...The main objective in our case, is to be able to show that effort was put into the user story that was put back into the product backlog, that even though we did not achieve our DoD for those US, team tried to, but for other reasons / impediments was not able to deliver.

Hi Fabio, I'm a bit confused, are those "Tasks" product backlog items themselves or are they part of an individual backlog item?

Anyway, if this is about a Product Backlog Item, I'd follow this recommendation:

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

The Scrum Guide quote above refers to Sprint Cancellations, however, I believe the same principle applies to unfinished backlog items during a Sprint. The idea is that the PBI should be highly transparent and reflect the current reality in order to facilitate better prioritizing decisions by the Product Owner.

In terms of PBI tasks, I'd suggest the Development Team review them on the next sprint planning and go with the alternative that better suits their way of working. Scrum has no specific instructions on how to split "internal" Development Team tasks. As they are self-organizing teams, I believe it's up to them to re-plan the work needed to complete the backlog item and determine whether or not they need new tasks.

However, I personally believe that the first option is more transparent and can be used for learning purposes in the future.

Cheers,

It is quite unfortunate you are using real hours as an estimation method, consider going more abstract - story points it's a good starter. For a scrum setup it is the best to not alter estimates for once estimated task and account full value into the sprint that got the task completed. This approach gives you highest transparency. 

• For reporting and monitoring puorposes you have clear situation: Velocity reflect really completed items.
• Velocity will be reflected in the velocity graph and you can then take an average from couple previous sprints as a forecast indication.
• Completed task is what matters. There is no value in 4 hours spent on unfinished task. It has strong psychological effect.
• This also forces PO to create smaller tasks.

If you keep writing off partially done task this may lead to situation that you may not finish a single task during a sprint and yet have successful Sprint. And this may drag over several Sprints with no valuable outcome (if you realize this extremum you will most likely be convinced to keep the full estimate for the next Sprint).

Excellent point guys, positively feeds even more our discussion, which is exactly what I'm looking for, different inputs and exchange good ideas.

Just to clarify, at the user story level, we estimate giving story points, but then at the task level, we estimate giving hours, which is exactly where the doubt came up, what to do with a partially developed task, since it was not finished within a sprint, therefore that particular user story did not achieve DoD.

From what I see here, there might be no right or wrong, but probably a more considerable option, which would be option 1, where it goes back to product backlog, and consequently will get to sprint planning and re-estimated if needed, which is what we ended up doing, but I wanted to get some external inputs as well, to see if we were way off or not by following option 1.

Thank you!