Re Estimating incomplete Stories

Mark, I believe you are answering your own question, in a way.

Story points are a planning tool to help the PO and the Development Team determine what amount of items is reasonable to expect to complete in future sprints.

Therefore, consider this.   When a sprint begins, all story points for those sprint items are meaningless.   The team has made their forecast, and can begin work based on communicated priority.

You seem to be approaching the issue like many do: "How do I get credit for partial work done on a sprint item?   The simple answer is that you don't, since story points serve as a planning metric.   Unfinished items are re-estimated based on work remaining, to provide clarity to the PO and Development Team to plan future sprints that may include that incomplete item.

Yes, velocity is a metric based on completed story points, to help guide the Dev Team and PO in their planning.   Velocity should never account for incomplete items, since Scrum is only concerned with items that meet the Definition of Done.

If the teams are selling themselves short and not accounting for the completed points after re-estimation...

Are you sure they’d be selling themselves short? They’d only be accounting for the amount of work that was actually Done. Is that really so unreasonable?

This is a confusing question. 

Why was this incompleteness not discovered in sprint planning? If it is incomplete and still allowed in the current sprint backlog HOUSTON we have a problem—you are setting yourself up for a failed sprint and carry over. You are pooching your velocity over time.

“Why are the points not added to the current sprint that have been complete.” – Because you are not completing it in the current sprint. It will be completed in a different sprint so it’s points go to that sprint it’s completed in.

If in the instance you re-estimate and maybe split the PBI to where you can complete part of the work and still have a value, then take the points you completed for that sprint. A PBI is ether done or not done. You don’t get half credit.

“Velocity is also used as a planning tool on what PBI's the team can take in to a sprint.” – No not in my world it’s just a metric over time per sprint. Not all my teams are consistent say taking in 15 points every sprint. It’s variable because not all the story sizes are known until sprint planning. I do use velocity over several sprints for forecasting but not always accurate. My teams never look at prior sprint velocity and say we need to take in at least 15 points. We do what is highest priority and value to the PO. The points are the points I don’t care what they come out to be.

Re-estimation happens. If my teams are re-estimating a story because it was bigger than they thought, there are multiple paths we take. Team always has to agree with the PO.

Given that story points are not described in the Scrum Guide, whether and how a team can effectively work with them is going to vary from case to case.

Scrum is an empirical framework, so let's follow an example scenario, and I'll make some assertions that could be taken in to account:

• The team had forecast getting items of a total estimate of 10 points to Done.
• The team got items of a total estimate of 7 points to Done.
• The team had forecast some work (estimated at 3 points) which did not get Done.
• The team did start working on the remaining items, but did not get them Done.
• The team did not take on any work which was not part of the original forecast.

This may be enough for the Development Team to realise that it can forecast at least 7 points of work in the next Sprint; because there is empirical evidence of them getting this much work "Done".

There is also empirical evidence that the team could not deliver 10 points of work, and that their previous forecast was perhaps too high.

The team might take in to consideration that it had some work in progress; but it is difficult to make an empirical judgement on the progress of incomplete work.

The logical conclusion is that, assuming the team don't have any evidence to see the situation being different the next time around, they should probably forecast at least 7, but less than 10 points worth of work.

If the team identify (perhaps during the Sprint Retrospective) why there were 3 points of undone work (e.g. working on too many things at once, or the items weren't broken down small enough), they may take this in to account when making the next forecast.

I have worked in a team where we identified that stories of 3 points or more tended to be underestimated. We used that information to make higher forecasts whenever we had lots of  ½, 1 or 2 point items in the backlog.

For me, the lesson in all of this is that once you move beyond the mathematics, and use story points as a tool for the Development Team to inspect & adapt their forecasts, you stop being a slave to velocity.

+1 Simon

Best explanation Simon !

Hi Simon,

Thanks for the explinaation.

The logical conclusion is that, assuming the team don't have any evidence to see the situation being different the next time around, they should probably forecast at least 7, but less than 10 points worth of work.

Another interpretation of this evidence, arguably more in line with Scrum-Kanban thinking, is that around 7 points worth of work might be forecast for delivery, while around 3 points might be available to the team for optimizing flow around the Sprint boundary.

Great explanation Simon