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 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

  • 3
    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 '18 at 14:09
  • What if it say 50% done? – Daniel Aug 8 '18 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 '18 at 20:52
  • When using Agile it is quite common to estimate the effort involved when pointing a ticket. My main point is that the points completed according to the definition of done does not necessarily reflect the amount of effort that actually happened in that sprint. I think that is wrong and can give a false picture fo the state of the project. – Daniel Sep 27 '19 at 13:29

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.)

  • 1
    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. – Daniel Aug 8 '18 at 15:49
  • 8
    @dan in that case completeing the hull and completing the furnishings had better be separate stories – jk. Aug 8 '18 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 '18 at 7:11
  • I agree that a boat about would probably be an epic. Perhaps an iceberg is a better example. Just because something is not visible, does not necessarily mean it does not add value. What you have worked on may be a dependency for something that is visible. In other words it would not be possible to deliver something that is visible if the hidden bit was not in place first. Either way there is effort involved and I think it is reasonable to attribute that effort to the sprint or time it was undertaken. – Daniel Sep 27 '19 at 13:37
  • 1
    @Daniel It is not the question if something is visible or not, it is a question if something is DONE. If your Task already added value after it reached 80% completion, but was so big that you did not finish it in the current sprint... then you did not break it down enough. If, for example the 7 day Tickt "Implement Load/Save functionality" also required that you "Refactor document classes" and "Add Cloud-based file handling"... then the latter two things should have been separate Tickets. – CharonX Sep 27 '19 at 14:19

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.

  • This is not a discussion about getting paid. In an Agile methodology I would expect to get paid for my time, not necessarily for the items completed in the sprint. That approach is more suited to waterfall. – Daniel Sep 27 '19 at 13:13
  • I do also think that one of the tenants of Agile is trust. As you say there could be many reasons why your team does not meet their expected velocity, however I would expect them to put in a consistent amount of effort from one sprint to the next. I think it is offensive to say that because a team did not meet their velocity, it was probably down to them not putting in the same amount of effort as say the last sprint. – Daniel Sep 27 '19 at 13:21
  • @Daniel, lets turn the argument around. You promised me a boat I can sail in, but by the completion date all I can see is some scattered half-completed parts of a boat. Why would I then pay you? You may have put in the hours, but you didn't deliver the promised product. – Bart van Ingen Schenau Sep 27 '19 at 13:57
  • The reason you would pay me is that I may be working towards delivering a boat, as someone else pointed out is probably an epic anyway. Even if you did not employ an Agile methodology it is likely you would stagger payments depending on certain targets being met etc. That may even include some money up front. Of course that approach is not really agile and does not incorporate a feedback loop. It also increases the chance of a complex project being a complete failure or nightmare to work on. – Daniel Sep 28 '19 at 13:59
  • 1
    @Daniel You promised to build a boat, upon completion you will get paid. This is what it means when "Build a boat" is a single Task. Of course it might be a bit... unwise to defer payment until that month-long job is done. So you should break things down: "Build hull" task, "Build superstructure task", "Add furniture" task - payment due for each individual step. Tasks still taking months (e.g. it is a big boat)? Break then down further "Build hull skeleton", "Build outer hull"... Your customer signs off each completed step and you get paid. – CharonX Sep 30 '19 at 11:44

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

When your ticket isn't finished by the end of the sprint it was planned in, is that inherently an issue? No. Why? Because estimates can be flawed. The point of retrospective is to not think that you can ever achieve the immutable objectively perfect measure of development planning, but rather to iteratively improve on issues that you weren't able to foresee.

Using that same philosophy, you cannot definitively state that 95% of the ticket is done, and you certainly can't start building on top of that as if it is an immovable fact.

Sprints and tickets are intended to be indivisible units, i.e. we count them in integer values, not decimals. When something takes longer than 1 sprint, we say it takes 2 sprints. We don't say that it took 1.25 sprints.

Similarly, a ticket is a whole unit. It is finished or it isn't. 95% effectively means nothing.

Can you retroactively start subdividing the ticket in a way that some subdivisions (the 95%) are completely done and others (the 5%) are not? Sure. Is it useful for developers to know which parts are done and which parts aren't? Of course. But that can be achieved by simple documentation within the ticket, it does not require further ticket management. Subdividing the ticket has no technical bearing and it's purely a number juggling trick. The only benefit to doing so is making the numbers look good on a spreadsheet, as opposed to focusing on the actual product you're trying to deliver.

Sprints exist not only to enforce recurring "state of the project" evaluations, but also to prevent continuous evaluations that are so frequent that they become a notable distraction from the actual development work. Trying to do some numbers magic on what is supposed to be an indivisible unit, just to make the numbers look good, violates that philosophy.

  • I agree with you that estimates can and often are flawed. A sprint can and often is measured in terms of points completed, and this is often compared with other sprints to see if the velocity of the team is going up or down, or remaining the same, I would expect the velocity of the team to steadily increase over time, however my point is that the points completed are not necessarily reflective of the amount of actual effort or work done in the sprint. I think this is misleading and can adversely affect planning for the subsequent sprint. – Daniel Sep 27 '19 at 13:05
  • I have worked at companies where certain employees are working in up to 3 or 4 Agile teams at the same time. With all the ceremonies, can you imagine how much time is left to do any work? – Daniel Sep 27 '19 at 13:31
  • 1
    @Daniel: Developers working in multiple agile teams is an antipattern. Besides the meetings you already mention, how can they accurately predict how much of their time they will be able to devote to each team? And being on multiple teams increases the amount of context switching you need to do, further reducing your effectiveness. – Bart van Ingen Schenau Sep 27 '19 at 14:02
  • @BartvanIngenSchenau: It's not impossible to be on more than one team, thugh I do agree 3 to 4 is a bit much. For example, we've had developers who had other duties (giving customer presentations) that took precedence over development. Therefore, we estimated their availability based on their appointments, and if they ended up being absent longer, we noted it as a bad estimate but with no real consequence to it, it was merely reported to the manager who oversaw those developers' tasks. This system can work, if the system is properly set up for it and the priorities are clear and agreed upon. – Flater Sep 30 '19 at 11:59
  • @Flater: It can work on one condition: During the sprint planning there is a clear estimate of the availability of each team member to do work for the team. I would treat such other duties similar to planned days off or training days. The problems come when the availability isn't know upfront, which it typically the case if you are a member of multiple scrum teams. – Bart van Ingen Schenau Sep 30 '19 at 15:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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