Story Points for PBI not done in sprint
During a sprint review, a scrum team had a PBI worth 13 story points that they had completed 90% of the work on it. Since the PBI was not "done" they moved the PBI back to the product backlog. When they did this they also updated the story points for the PBI from the original 13 value down to 1 so that it reflected how much work was remaining to be done. So their velocity did not take into account that the team completed 90% of work on a 13 story point PBI.
Do you recommend any changes to what this team did as it pertains to the story points?
Very strictly speaking, the team should not have moved the item out of the Product Backlog in the first place, since it did not represent work which had been done. The estimates for the work which is believed to remain should always be accounted for on the Product Backlog, even if some of that work is currently in progress on a team's Sprint Backlog.
As regards the team's velocity calculation, their method is correct if it helps them to forecast how much work they can take on in the future when building an increment of release quality.
Daniel,
If you keep in mind that velocity should be used by the PO and team as a planning metric only, and never as a reflection of effort or productivity, then you'll know the answers to the questions you're asking.
Put another way, velocity should be based on the work a team completes in a sprint. Does it make sense to include unfinished work in a team's velocity calculations, even if it was estimated at 90% done?
From your post, it is my opinion that the team managed that unfinished item very well (re-estimating, putting it back in the Product Backlog).
@ Ian:
the team should not have moved the item out of the Product Backlog in the first place, since it did not represent work which had been done.
Unsure what you're referring to here Ian. If I read Daniel's post correctly, his team took on a 13 point story in a sprint, almost finished it, and moved it back to the Product Backlog at the end of the sprint with a new "remaining work" estimate of 1.
Why would work be removed from the Product Backlog in the first place, if it was needed but wasn't actually finished, and then have to be subsequently moved back?
Strictly speaking work should not be removed from a Product Backlog once it is planned into a Sprint Backlog, since it still constitutes remaining undone work. Work is not as good as Done just because a team has it in progress. Sprint Planning involves selecting work from the Product Backlog, not moving it from one backlog to another.
Work should only be retired from the Product Backlog once it is found to be unnecessary, or an increment which encompasses the corresponding scope is Done.
Correct me if I'm wrong, Ian, but I think that when work is selected for a Sprint, it tends to disappear from the Product Backlog, and a Product Owner will then treat the Backlog as up to date or accurate.
The truth is, the work in the Sprint Backlog is still undone and should be considered so up until the point it is done. Undone work should be reflected on the Product Backlog. I suppose the Product Owner just needs to keep in mind that a portion of the backlog is in progress when 'monitoring progress toward a goal'.
It took me five long minutes to write a very small comment and Ian responded before me. Great stuff.
I think that Alex makes a fair assessment of this.
It is certainly a common assumption that work is "moved" from the Product Backlog to the Sprint Backlog during Sprint Planning. However, it is strictly incorrect, because that work isn't actually Done and it would mean that the Product Backlog no longer tells the entire truth about the remaining work.
If I understand correctly, my statement around PBI's moving from one backlog to another was mistaken. If that is the case, point taken. Please let me know if any other part of my understanding regarding unfinished sprint work is incorrect.