How to handle stories that were not completed

Last post 03:34 pm September 24, 2020
by Richard Uphill
19 replies
Author
Messages
01:06 pm September 20, 2018

Hello,

We just started our first scrum project, and I'd like to clarify how stories that were not completed should be handled, specifically for the é following 2 cases:

1) The team did not have enough time to implement it correctly and it's not usuable at all.

     In that case, I think we should just put the story in the next sprint (if possible) and re-estimate its points. We don't add any points to the total for the current sprint as the story is not complete at all

 

2) The team almost finished the story, but it's missing something for it to be accepted (small bug, or logo/image not completed yet by the designer, who's part of the team) . 

     In that case, do we count any of the story points in the current sprint's total number of achived points? If yes, do we mark that story as 'completed' and create a new story to fix the bug/add missing logo? Or do we keep the same story and modify it to indicate that it's missing complete (but what of the points in that case?)

 

Thanks

06:15 pm September 20, 2018

First of all strive to come to the state where stories will be completed. But in case stories are not completed, you have two options.

1. Split

2. Carry forward

I had a discussion with Agile coaches on the same point.

They offered the following distinctions:  If you SPLIT a story, the team will not get credit for the points (since they didn't deliver) but they will get credit for the hours worked.  If you MOVE a story, then the team will not get credit for the points NOR will they get credit for the hours.  IN ANY CASE, YOU SHOULD NOT CHANGE THE POINTS ON THE STORY.  If you change the points when you move and/or split, the team will not get credit for the points in the first iteration AND when the do get credit it will be for less points since the point value was changed.

Splitting of stories also highlights the fact that the team has not been able to deliver what they have committed (in terms of a story) and thus, there is some scope of improvement (planning, solution, requirements accuracy or implementation). This would strive the team to focus on the issue at hand and thus, would help the team evolve from agile as well as delivery perspective.

06:54 pm September 20, 2018

1) The team did not have enough time to implement it correctly and it's not usuable at all.

     In that case, I think we should just put the story in the next sprint (if possible) and re-estimate its points. We don't add any points to the total for the current sprint as the story is not complete at all

2) The team almost finished the story, but it's missing something for it to be accepted (small bug, or logo/image not completed yet by the designer, who's part of the team) . 

     In that case, do we count any of the story points in the current sprint's total number of achived points?

I think your reasoning in the first case seems fair and sensible.

What though do you believe is so critically different, in the second case, to justify the “counting” of any points for that story in the Sprint? Why do you think it might now be right to do so, in this instance?

06:20 pm September 24, 2018

IN ANY CASE, YOU SHOULD NOT CHANGE THE POINTS ON THE STORY.  If you change the points when you move and/or split, the team will not get credit for the points in the first iteration AND when the do get credit it will be for less points since the point value was changed.

Per the Scrum guide (found in the sprint cancellation section, but applicable to any incomplete SB items):

"All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog."

The motivation should not be around getting credit for work done.   Items are either complete or incomplete.   It is a poor practice to encourage teams to claim credit for partial work.   This isn't about them, but about what value the business is receiving from them each sprint.

Splitting an item (i.e. - completing an item but moving its cosmetic defect as a separate item for a subsequent sprint) can result in closing the item and creating/estimating a separate item.   Moving an item intact should not result in any points credited to the team.   How does it help a team to base their velocity on incomplete items?   How much waste is involved in having teams evaluate what portion of an incomplete item is actually complete, and how that should translate into completed points vs incomplete points?   

Keep in mind also that story points (or other relative estimation methods) are for planning purposes only.   It does not help the team (and creates waste around conversion/translation) to keep estimates intact when moved out of a sprint instead of re-estimating the remaining work.

 

 

08:00 am September 25, 2018

IN ANY CASE, YOU SHOULD NOT CHANGE THE POINTS ON THE STORY.  If you change the points when you move and/or split, the team will not get credit for the points in the first iteration AND when the do get credit it will be for less points since the point value was changed.

"We do not deliver points. We deliver value" - The author of this sentence is a developer from my former team. Do you see the point? Story Points are useless, if you don't have the Increment. 

10:52 am September 25, 2018

Hello David, 

Acceptance criteria plays very important role in estimating and completing the User Story. If Development Team has achieved acceptance criteria of that particular user story. They can go ahead and close it. BUT even if a small thing is yet be finished then user story will be considered incomplete. 

1. As you explained that team could not complete the user story then in that case, Story should put back to Product Backlog. Scrum Team should re-evaluate the importance of user story. If user story needs to be completed to achieve sprint goal then it should be carried forward to upcoming sprint. 

2. As i mentioned above, if user story does not achieve acceptance criteria then it will not be considered as complete.Either it can be put back to product backlog or can be moved to upcoming sprint. Depends upon business requirement and importance of that user story. 

I hope, i was able to answer your question. 

 

10:56 am September 27, 2018

Thank you all for your answers.

 

To answer Ian's question

What though do you believe is so critically different, in the second case, to justify the “counting” of any points for that story in the Sprint? Why do you think it might now be right to do so, in this instance?

In the second case, the uncomplete work in the story is not a showstopper.  Most of the 'heavy work' has been done by the developpers, but the designer failed to deliver a logo or background image in due time. The feature is still usable as such, e.g. "As a public user I can log in the website using the 'log in' button", but that button is missing an icon next to the 'Log in' label.

 

My main motivation for counting points for uncompleted stories  is that I'm afraid of the impact of 'almost completed' stories on velocity and other indicators. 

For instance, take the case where  the team works on a story with a high number of points, almost completes it, but does not get any point for it. The story will then be completed in the next sprint, but will not worth many points since there was not much work left to do..

As pointed by Timothy, points are for planning only; however in this scenario (no points), this will lower the velocity (on average) and might lead to the impression that the project will take longer to complete than it will

 

 

11:45 am September 27, 2018

My main motivation for counting points for uncompleted stories  is that I'm afraid of the impact of 'almost completed' stories on velocity and other indicators. 

For instance, take the case where  the team works on a story with a high number of points, almost completes it, but does not get any point for it. The story will then be completed in the next sprint, but will not worth many points since there was not much work left to do..

As pointed by Timothy, points are for planning only; however in this scenario (no points), 

My advice is to rethink the idea of a team "getting" points and of them having "worth". Neither of these are in line with the principle that they ought to be for planning only.

this will lower the velocity (on average) and might lead to the impression that the project will take longer to complete than it will

If the partially completed work is being re-estimated on the Product Backlog, then any such impression would be false, because less work would be thought to remain.

12:25 pm September 27, 2018

I think you should not focus this the problem in terms on how to deal with uncompleted Sprint backlog items in terms on splitting them to give credit to the development team. In the Scrum Guide it's clear how to deal with that as Timothy pointed

"All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog."

I'd suggest to tackle this issue during the Sprint Retrospective with the following Questions in mind:

  • Where the Backlog Items correctly splitted?

    • During refinement and Sprint planning?
    • Did the development team notice before the end of the sprint that those items could have been splitted better?
  • Does the Definition of Done need to be adjusted?
    • Do you need design to get items Done?

I understand that your main concern is how to deal with the actual situation so, follow the Scrum Guide and encourage the team to find a way to avoid uncompleted tasks in the future.

 

 

01:42 pm September 27, 2018

In the second case, the uncomplete work in the story is not a showstopper.  Most of the 'heavy work' has been done by the developpers, but the designer failed to deliver a logo or background image in due time. The feature is still usable as such

A few thoughts here:

  • Was the logo part of the original acceptance criteria of the item?   If not, then was it missed in refinement (missed requirement)?   If yes, then it would be the PO's decision whether to accept the item as delivered (usable), or reject it because it was incomplete
  • Who is the "designer" here?   Is this a specialist within the Development Team, or an external dependency?   If external, what is the history with delivery within the sprint from this dependency?   Should the Development Team even accepted the item if they were unsure whether the logo could be delivered by this external dependency in time?
  • If the designer was a specialist within the Development Team, then you should note that in Scrum, it is critical to emphasize Team Ownership of all sprint items.   Work does not belong to a single individual, so it is fundamentally incorrect to state that the "designer" didn't deliver the logo.   The Team didn't deliver the logo
  • Velocity is a guiding metric for teams to use in planning, and should be based on completed work only.   It seems incredibly wasteful to me to expand this practice to include portions of incomplete items

 

03:34 pm September 27, 2018

@Ian

If the partially completed work is being re-estimated on the Product Backlog, then any such impression would be false, because less work would be thought to remain.

I don't agree with that, but maybe my logic is flawed. Take  a 1000 point backlog when project starts. During sprint 1, the team agrees on doing 126 points, so there are 874 points left in the backlog. At the end of this sprint, say that:

  • the team gets 80 points for fully completed stories
  • two 13 point stories are not completed, so they are  re-estimated at 1 point each (it was not missing much, just an icon or there is a small bug) and put back into the backlog, which has now a total estimate of 876
  • Team velocity is 80

With that velocity, a rough estimate is 876/80 = 10.9, so 11 sprints left at this pace. But if the team was granted partial points for their work on the 2 uncompleted stories, say 10 points for each, then velocity would be 100. This would lead to an estimate of 876/100 = 8.7, or 9 sprints left to complete the items currently in the backlog.

 

 

If the designer was a specialist within the Development Team, then you should note that in Scrum, it is critical to emphasize Team Ownership of all sprint items.   Work does not belong to a single individual, so it is fundamentally incorrect to state that the "designer" didn't deliver the logo.   The Team didn't deliver the logo

The designer is indeed a specialist in the team, and no, the idea was not to blame him.

 

Velocity is a guiding metric for teams to use in planning, and should be based on completed work only.   It seems incredibly wasteful to me to expand this practice to include portions of incomplete items

 

Same as above my response to Ian. I do understand that it is for planning, but  I feel that it'd lead to skewed measurements (see axample above)

@ana

 

  • Where the Backlog Items correctly splitted?

     

    • During refinement and Sprint planning?
    • Did the development team notice before the end of the sprint that those items could have been splitted better?
  • Does the Definition of Done need to be adjusted?
    • Do you need design to get items Done?

Maybe we are using the wrong approach, but we don't want to have stories that are too short (they take between 1h and 3 days of work). In the example I'm using, it did not feel right to split a story between design and functionality, since the design part was limited (e.g. creating an icon). For later sprints, we'll decided to split the designer's stories from the other stories, so that he can work on it in advance.

 

And modifying the Definition of Done to say "it works, but design does not need to be finished" does not feel right either

04:34 pm September 27, 2018

David,

I don't agree with that, but maybe my logic is flawed. Take  a 1000 point backlog when project starts. During sprint 1, the team agrees on doing 126 points, so there are 874 points left in the backlog. At the end of this sprint, say that:

  • the team gets 80 points for fully completed stories
  • two 13 point stories are not completed, so they are  re-estimated at 1 point each (it was not missing much, just an icon or there is a small bug) and put back into the backlog, which has now a total estimate of 876
  • Team velocity is 80

With that velocity, a rough estimate is 876/80 = 10.9, so 11 sprints left at this pace. But if the team was granted partial points for their work on the 2 uncompleted stories, say 10 points for each, then velocity would be 100. This would lead to an estimate of 876/100 = 8.7, or 9 sprints left to complete the items currently in the backlog.

Yes, you would have two different forecasts based on whether you counted incomplete work or not.   But how accurate would such a forecast be if it tried to consider incomplete efforts?   

And how much wasteful effort would teams/PO's have to use to calculate what the partial points would be for incomplete items?   

And what is the incentive to the team to actually reach Done at the end of the sprint, if they're encouraged to just carry items over from sprint to sprint?

And how does the concept of unfinished items help the PO to forecast completion dates?

 

If I may make a suggestion, this may help:

Use story points to help the Dev Team / PO plan a sprint.   Once the sprint starts, throw the points away.   Don't even look at them anymore.   

The only time sprint backlog items should ever care about their story point value again is if it is either complete (to include in velocity calculations), or if it is moved out of the sprint or left incomplete at the end of the sprint (re-estimate remaining effort for future planning purposes and place in backlog).

You'll thank me later.   ;-)

 

05:07 pm September 27, 2018

Take  a 1000 point backlog when project starts. During sprint 1, the team agrees on doing 126 points, so there are 874 points left in the backlog.

Strictly speaking, there are still 1000 points left in the backlog, regardless of any agreement, because none of the work has yet been done. The Product Backlog should always show the amount of work which is currently understood to remain.

At the end of this sprint, say that:

  • the team gets 80 points for fully completed stories
  • two 13 point stories are not completed, so they are  re-estimated at 1 point each (it was not missing much, just an icon or there is a small bug) and put back into the backlog, which has now a total estimate of 876
  • Team velocity is 80

In the situation you describe, the team appear to have planned in 80+13+13=106 points.

By the end of the Sprint, fully completed stories account for just 80 points of work, so the team's velocity is 80. That leaves 1000-80=920 points in the Product Backlog. Re-estimating the two 13 point stories down to 1 point each means that each is reduced by 13-1=12 points. The backlog therefore shrinks by a further 2x12=24 points. 920-24=896 points remain.

A calculation based on velocity would suggest 896/80=11.2 Sprints remaining (i.e. 12 Sprints needed). However, the 24 points (which constitute the work partially completed) are accounted for as work which no longer remains to be done. A suitable projective technique, such as a product burndown chart, would show a reduction in the size of the Product Backlog of 80+24=104 points. The number of Sprints remaining may then be projected, using the chart, to be 896/104=8.62, or 9 Sprints.

The key thing is to properly account for the work, and to use appropriate projective techniques that tell you as much as possible from the data you've got.

08:35 pm September 27, 2018

I think one point that everyone is missing is that you don't use actual velocity of the previous sprint to do forward planning. You use an average or an average range of past velocity.  So given that, does it really matter if a story is moved out of a sprint and into the next as is?  The points given to a story is an indicator of the complexity of completing the entire story.  So if in this case, they did the entire story except adding a single non-functional visual element.  Is that really so bad?

Honestly, here are the 2 alternatives I'd suggest to the team:

  1. Complete the story in the current sprint and do the 20 minutes of work needed to add the icon in the next sprint without a story.  It would take longer to do all of the story management than it would to just do the work and be done.
  2. Move the entire story as is with it's current points into the next sprint and then do the 20 minutes of work.  Take all of the points credits in the next sprint.  Then when start looking forward, the average velocity is still going to be about the same.

Sometimes we try to make things harder than they need to be.  Agile is about transparency, inspect, adapt.  Scrum isn't about "getting points".  It is about delivering value in increments.  In this case, you delivered significant value with a minor cosmetic problem.  Quit trying to make it harder than it really should be.  Discuss why the logo was late in the retro, learn from that.  Teach the team the value of delivering value and not being punished for missing a logo.  And for heaven's sake, deliver the value and move along. 

09:03 am September 28, 2018

Thank you all for your responses.

@Daniel

I think one point that everyone is missing is that you don't use actual velocity of the previous sprint to do forward planning. You use an average or an average range of past velocity. 

Yes that is true, but if the problem will remain if this scenario occurs repeatedly (of course, this would mean that we have a problem somewhere)

However, i'm not sure if just doing the extra work without proper tracking is scrum-like

@Ian,

A calculation based on velocity would suggest 896/80=11.2 Sprints remaining (i.e. 12 Sprints needed). However, the 24 points (which constitute the work partially completed) are accounted for as work which no longer remains to be done. A suitable projective technique, such as a product burndown chart, would show a reduction in the size of the Product Backlog of 80+24=104 points. The number of Sprints remaining may then be projected, using the chart, to be 896/104=8.62, or 9 Sprints.

The key thing is to properly account for the work, and to use appropriate projective techniques that tell you as much as possible from the data you've got

 

Exactly, 2 different estimates. And in 2nd one, you do count 'partial points', so this impacts velocity (even if you don't call it that, and maybe that's my problem). How do I know which estimate I should use? For me, it should be the 2nd one

 

@Timothy

And how does the concept of unfinished items help the PO to forecast completion dates?

 

For me the team has produced value in 'almost complete' tasks, so this has a direct impact on forecasting (as example above). 

09:23 am September 28, 2018

And in 2nd one, you do count 'partial points', so this impacts velocity (even if you don't call it that, and maybe that's my problem)

No, there aren't any "partial points". The amount of work which is estimated to remain is reduced, and work which is Done is measured separately. That's it.

The way language is used in Scrum is important, because it is valuable to transparency.

06:07 pm September 28, 2018

Yes that is true, but if the problem will remain if this scenario occurs repeatedly (of course, this would mean that we have a problem somewhere)

That is true.  You do have a problem somewhere, but Retrospectives are for discussing that type of issue.  I'm not saying to ignore the fact that stories are incomplete. I'm saying that putting too much effort into splitting stories or the exercise of reevaluating the points is not the solution to that problem. It actually hides the problem and makes it seem like it is normal because "scrum has a way to handle it".  I think the problem needs to be discussed and addressed in much more debt. Get to the root of why stories are not being complete and fix those problems instead of trying to find a way to obfuscate the issue. 

03:05 pm October 8, 2018

Very good contributions here, kudos everyone.

Re "With that velocity, a rough estimate is 876/80 = 10.9, so 11 sprints left at this pace. But if the team was granted partial points for their work on the 2 uncompleted stories, say 10 points for each, then velocity would be 100. This would lead to an estimate of 876/100 = 8.7, or 9 sprints left to complete the items currently in the backlog."

I'd like to add that, for all the transaprency you, the whole team, the managers and the organization "itself" are genuinely throwing in, though on paper (for Ian had explained the reality and pointed out the proper burndown use) it may look as there is a discrepancy and therefore incorrect data (11 vs 9 sprints), in reality it's always good to have a cautious approach, especially in software projects (everyone knows that).

Not to mention likely future changes to the backlog (based on stakeholder input/market changes) that may increase (most always) or decrease the required effort. Throw in technical debt > refactoring, code defects, and you're in for a treat.

And, even if the business expects completion, based on "current" effort of 876 points, in 11 sprints, there would be no complaints if completion takes 9 sprints.

As many had said before me, don't even bother about points - they're supposed to show the relative effort thought to be needed to create a product/feature that ultimately brings value for the business. So focus should be on value delivered per increment, and as a whole (per all increments), not number of points completed per increment.

04:42 am May 8, 2020

While working on the user stories, we create the tasks for the user stories.

At the end of the Sprint, we only move the left over tasks to the next sprints and not the entire user story.

We don't change the story point. The credit will go the the sprint in which the user story is resolved meeting the acceptance criteria.

 

Thanks

02:55 pm September 24, 2020

It seems to me we are getting confused between delivering value and estimating the effort involved in delivering that value.

Story points are used to comparatively estimate, based on past work, how much effort it will take to deliver a story. With this knowledge the development team can get a feel for what effort is required to deliver the value in an upcoming sprint and to aid in sprint planning.

If an 8 point story is not 'done' then zero value is delivered. The credit should be the team delivering the value not burning points.

not completing a story should be an exception and as others have said the team should discuss the story/sprint in the retro - inspect, learn and adapt with a view to being a bit wiser for the next time.

Formally the story should then move to the backlog to be reviewed again by the PO. If the story is picked up again then the story should be re-estimated. It may be that there is more effort required to deliver the story than was ever known, maybe it needs to be split into different stories now that we understand more, conversely it may be that the work left to do is now less as some of the work has been done. If the story is not re-estimated the effort to deliver the value of the story is not clear for the PO or the team.

It's at this point everyone gets hung up on the lost velocity points - well, remember velocity is an average and small changes like this will not make much of an impact to the velocity. Remember, the velocity is there to help the team deliver value not a metric for managing performance per se.