I have been working with Jira within an Agile scrum like methodology for a while now. What happens quite often is a ticket is estimated and started on. By the end of the sprint 95% of the work is done. What usually ends up happening is that this ticket is dragged over to the next release iteration to complete the 5%.

My issue with this is that this approach is it:

  • distorts the picture of what is happening in the sprint
  • does not reflect the amount of effort that actually occurred in the iteration
  • overestimate the amount of effort that is carried over
  • demotivates people as this does not reflect the effort involved or required.

One solution to this would be to clone the ticket at the end of the sprint and then reassign the points bassoon an estimate of:

  • what has been done
  • what is left to do

e.g. say you have ticket that is pointed at 8 points, and it is all but done barring some minor changes. We could say that the ticket is 90- 95% done. Then why not clone the ticket, and carry it over as a 1, while reducing the previous ticket by one and leaving it in the previous iteration

  • 2
    I'm very sceptical of tickets which are 95% done, especially if it's happening quite often. If there are only some minor changes remaining, do the changes and close the ticket before the sprint ends. – John_C Aug 8 at 14:09
  • What if it say 50% done? – dan Aug 8 at 15:37
  • If a task is 50% done then it's definitely not done. You're asking how to make this situation less painful but it's supposed to be a bit painful to discourage teams from over committing. – John_C Aug 8 at 20:52

If at the end of your sprints often you have many big tickets that are 90% - 95% done then there is something wrong:

Red flag #1: Lots of things get packed into a sprint but are not finished
Red flag #2: You have many big tickets
Red flag #3: For some reason this affects the "last" 10% of progress

Let's adress those things first:
1: If you repeatedly have leftover tickets you either over-estimate your velocity or underestimate the story-points of tasks. Both things can and will happen occasionally, but this should not be a persistent situation.

2: If the you have many "big" tickets sitting at 95%, it means you have many "big" tickets, which in turn may be a sign that you are not breaking down the tasks small enough.

3: I somehow feel dubious about those missing 10%... either something is persistently going wrong at the very end of many tasks (Insufficent testers to test them? No enough hardware?) or those are the tasks where you finish 90% of the work in 3 days, and the remaining 10% in 3 more days. Verify that 90% really means 90% and that there are no bottlenecks.

Now to you question:

No, do not clone the ticket and fudge the numbers. Learn from the experience, and break the tickets into smaller, better chunks. If a handful of half-a-day tickets get carried over, that can happen (especially when you realize that you have time left over before the end of the sprint and pull in more tasks), but a handful of half-days is within the margin of error for scrum planning.

Remember that task that is not DONE has - for the stakeholder - zero value. A boat that is only 90% watertight will not work/float (for long), nor will a feature that is only 90% DONE (i.e. implemented AND tested, etc.)

  • A hull of a boat may be watertight, but perhaps the furnishing is not complete. Therefore the boat is not complete but would still provide value, especially to those in dire need of water transportation. I think this is like a Minimum Viable Product or lean methodology. – dan Aug 8 at 15:49
  • 3
    @dan in that case completeing the hull and completing the furnishings had better be separate stories – jk. Aug 8 at 16:28
  • @dan In that case the task "build a boat" would be an epic, containing (among others) the "assemble a watertight hull", "assemble the superstructure" and "add furnishing" subtasks. "The hull is 90% done (there is still a 5x5 hole in the middle)", "the superstructure is 90% done (the stairs and ladders are missing)", "the furnishing is 90% done (the benches and tables are on board, but not secured, so they slide freely across deck)" - all of those prove no real value until the missing 10% are done too. And as jk said - if floatation is their concern "watertight hull" should be a priority task – CharonX Aug 9 at 7:11

The idea behind putting a story that has not been completed in its entirety on the next iteration (or the backlog) is that the team should not get credit for unfinished work. This should give the team an incentive to actually finish the work before the end of the iteration.

The burndown in Scrum also works this way. It only shows points burned if the associated value has been realized by completely finishing the work. 95% done means the work isn't finished and isn't ready to be handed over to the stakeholders, so why would you get paid (by burning the points) for it. And although you say it is 95% done, in my experience those last few percents take way more time than the rest, so 95% done probably corresponds to 7 points (out of 8) of work remaining.

If carrying work over from one iteration to the next is common enough that it starts to affect the team motivation, you should address the reasons why the work doesn't get completed within the iteration.
It could be that people are not collaborating enough to finish up the work (starting on a new task is more fun that doing that final review to get the other one to done), or it could be that the stories are simply too big.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.