Unclear how to handle unfinished User Stories in regard to storypoints/estimation

Hi Joost,

"a) In my opinion, velocity means; sum of the storypoints for finished userstories in the sprint. So the velocity of sprint 1 is 11 storypoints(story a + b). Is that correct? Some people say the velocity is 14 (story a + b + 80% of c)."

It is absolutely correct because c was not Done, as such it should not be considered.

"b) In my opinion the team should re-estimate story C to 1 storypoint (based on work left, complexity,risk,etc). What is your opinion? In what event would you re-adjust, Sprint Review or Planning?"

Most practitioners(myself included) are of opinion the unfinished work has to be re-estimated and added to the backlog for further consideration (if really important, PO would want it in the following sprint). This view is in Scrum Guide's spirit (sprint cancellation topic). The re-estimation can happen at any point prior to sprint end, but definitely not during sprint review (which has other purposes), and maybe not during retrospective (when you could potentially re-estimate, but focus should be on why the problem arose). Use some time after a standup for example.

"c) When planning sprint 2, the PO prioritized story C at the top of the product backlog. Based on sprint 1, what velocity should the team use? 11 points or 14 points?"

If the development team is certain they can complete (requirements are reasonable, test acceptance is clear), it would normally be added in sprint 2. 

In terms of velocity, the Scrum Team should stick with 11 points, then, at the end of sprint 2 it turns out there were, say, 17 points done, in planning sprint 3, the team may consider taking 14 points (11 + 17 / 2) in sprint 3. And so forth - inspect and adapt based on the proved velocity.

The re-estimation can happen at any point prior to sprint end, but definitely not during sprint review (which has other purposes)

The Scrum Guide says that "The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint".

A Product Backlog should always capture, as accurately as possible, the amount of work which is believed to remain. Hence re-estimation may occur during a Sprint Review.

Hi! Here my considerations about it.. :)

a) You are right. The done increment is represented by stories A and B, not C, so you shouldn't consider points of story C as done.

b) Once you don't consider the story points of C on the sprint 1, you should consider all the story points on the sprint 2. When you calculate the team's velocity at the end of the sprint 2, all the story points of work done will be considered.

However, if you use all the story points of story C on the sprint 2, you will underestimate how many work your team can do on this sprint (80% of story C is already done, that is zero effort). So, my guess is that you should understand with your team how many work is needed to finish story C (in story points or not) in order to estimate a reasonable number of stories to do on the sprint 2.

I don't think you should manage the unfinish work of story C in the Sprint Review. On a stackholder's point of view, the story C is undone (nothing more, nothing less) and should be just prioritized on the Product Backlog at this time as an undone story. The moment when you will manage the unfinished work is on the Sprint Planning of sprint 2.

c) The team's velocity is the average of historical number of story points done on each sprint. So, for this sprint you should not consider 14 points, only 11 points. On the next sprint you will use all the points of story C to calculate the new team's velocity and, on the historical average, everything will be fine. :)

The Scrum Guide says that "The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint".

A Product Backlog should always capture, as accurately as possible, the amount of work which is believed to remain. Hence re-estimation may occur during a Sprint Review.

Thanks, Ian! So my practice hasn't been spot on in this regard. You are absolutely right to point it out.

The Scrum Guide says that "The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint". 

To add to this; the book Scrum - A Pocket Guide by Günther Verheyen states this very clearly too; During review you inspect the work "Done" and adapt on the backlog. So this means estimations, too. Maybe new insights or desirements are obtained through stakeholders. Re-estimating the items affected during, for example, Sprint Planning would mean a decrease in transparency.

Story C - 5 Storypoints --> Not finished, 80% done, testing left.

Using the above as an example, I've seen some Scrum Masters splitting the story towards the end of the sprint and taking credit for work that has been completed. In this case, for example, the story would be split into a 3 point story for the work that has been completed in the sprint about to end, and the remaining work (testing) to be carried out in the next sprint as a 1 or 2 point story. In my opinion, I see no value in this as the points do not earn you anything as they are arbitrary in the first place.

What is the opinion of the community on this practice?

Also, to ensure I understood the above discussion clearly, when this 5 point story is partially completed but is still considered for the next sprint, then it is re-estimated and a new story point is assigned? i.e. the story would be carried forward to the next sprint with all the completed tasks but could now be only worth a 1 point.

The answer to that would be interesting because that would mean we are also following something incorrectly and placing too much emphasis on the word points.

Using the above as an example, I've seen some Scrum Masters splitting the story towards the end of the sprint and taking credit for work that has been completed. In this case, for example, the story would be split into a 3 point story for the work that has been completed in the sprint about to end, and the remaining work (testing) to be carried out in the next sprint as a 1 or 2 point story. In my opinion, I see no value in this as the points do not earn you anything as they are arbitrary in the first place.

What is the opinion of the community on this practice?

Are those stories genuinely valuable to the Product Owner, and can be released independently? If so, why was the larger item not refined into those stories beforehand? Would the "testing" work you mention actually constitute a good, well-formed user story?

Also, to ensure I understood the above discussion clearly, when this 5 point story is partially completed but is still considered for the next sprint, then it is re-estimated and a new story point is assigned? i.e. the story would be carried forward to the next sprint with all the completed tasks but could now be only worth a 1 point.

The answer to that would be interesting because that would mean we are also following something incorrectly and placing too much emphasis on the word points.

If 1 point of work was genuinely believed to remain, why would revising the estimate accordingly be incorrect?

Using the above as an example, I've seen some Scrum Masters splitting the story towards the end of the sprint and taking credit for work that has been completed. 

I don't believe that pointing Product Backlog items should be done for the sake of getting credit.  Often times people will debate whether a spike should be 'pointed'.  Since spikes are time-boxed, you already have an estimate.  When I ask why bother estimating a spike, the answer I hear is 'to get credit'.  Those points don't equate to value delivered or productivity. 

Are those stories genuinely valuable to the Product Owner, and can be released independently? If so, why was the larger item not refined into those stories beforehand? Would the "testing" work you mention actually constitute a good, well-formed user story

@Ian, the original story would have constituted development, unit testing, migrate to pre-prod environment, and test in pre-prod environment for that piece of work to be considered complete, however, what i've seen happening is that the actual development effort itself is too big, which forces some of the tasks to be carried over to the next sprint. Similar to how the original poster mentioned, if testing is all that remains,  then the team splits the story (at the end of the sprint) to take credit (don't know how this practice came up) for the tasks (within that story) that are complete. Without testing, no, that piece of work cannot be promoted further.

That brings another question to mind. Should a story be created for Migrating code to Prod? or would this be classified as a spike?

Are there any standard points/definitions to reference to ensure something qualifies as a story, user story, or spike?

If 1 point of work was genuinely believed to remain, why would revising the estimate accordingly be incorrect?

To clarify, what I was asking was, If the original story was 5 points, consisted of  development, unit testing, migrate to pre-prod environment, and test in pre-prod environment, and assuming everything except testing was complete, the correct way this would have to be tackled in the next sprint is to re-estimate and perhaps revise it to a point value less than 5, assuming testing is a minor effort or won't require the same amount of time as the rest of the tasks. In essence this same story in the next sprint would now meet the DoD when testing is complete but is no longer worth the same points.

I'm surprised that no-one has challenged the assertion that Story C is indeed 80% done.

80% is in itself is an estimate, and often such estimates are not treated empirically. 

Scrum relies on empiricism, and it is very hard to be certain about not-done work. Who says testing goes smoothly? Maybe during testing, the team find that their proposed solution makes the product unsustainable, and they have to rework it.

Similarly just because a team feels it is 80% of the way there, who says their original estimate was correct? They may have found, after working on the story that it was easier or harder than they originally estimated, so they may feel they are 80% through something that (with hindsight) should not have been estimated at 5 points.

The team should feel free to re-estimate the remaining work on this incomplete item as accurately as possible. This could involve giving it a higher estimate than it had already. Focusing too much on velocity usually gets in the way of good estimates, and that's more damaging.

Imagine the team re-estimate the partially completed item, realise they had underestimated previously, and now decide there are 8 points of work remaining. It would be nonsense to claim that the team did -3 points of work on the item. Save yourself the complexity, and just disregard incomplete items from the velocity calculation.

At the next Sprint Planning, the Development Team can use velocity, plus any other factor they consider relevant, to forecast what they believe is achievable within that Sprint.

Work in progress being carried over from one Sprint to another should be an edge-case. Don't optimize for edge-cases, because it's very hard to be empirical about them.

Instead, focus your energy on splitting items into smaller pieces of work, so that there is less partially completed work at the end of a Sprint. If you only have a 1 point item partially done at Sprint end, you might find that its impact on velocity is negligible.

Furthermore, smaller items are usually easier for a team to predict, and so they may use the final hours of the Sprint picking up and completing an item they can get to "Done", thereby decreasing the chance of finishing with work in progress.

So, the bottom line is that if a story which has been estimated with a higher story point, has been partially completed, is still valuable to the PO, then it should be re-estimated when being taken as part of the next sprint, Correct?

The uncompleted story should be re-estimated on the Product Backlog regardless of whether or not it goes into the next Sprint. A backlog should always tell the truth regarding how much work is thought to remain.