How can I track what was done inside the sprint if I move the incomplete tasks to next sprint?

[Rebeca Luna]

Should I clone the task and move just the cloned one to next sprint keeping the original inside the closed sprint? 

Is there another way I can easily see the work done by sprint? Because even not finished the task I need to know all job done inside the sprint.

[Kelly Albrecht]

Completing a sprint with in progress stories, with some subtasks done and others not, will let you move what's not done into the Backlog. The story goes back, because with subtasks still open, it is not done yet. 

The reasoning behind this is that subtasking is just a way to breakdown a story, but subtasks are not considered tasks on their own. While some subtasks were in fact completed in a sprint, they are really just part of their Story task, which if all of its subtasks are not done, then it is not done. A sprint will show an in progress story's completed subtasks for context no matter which sprint they were completed in.

You might consider trying to break your epics in to smaller stories so that any and all of a story's subtasks will get completed during a sprint.

You could also consider whether your larger stories would make more sense as Epics. Then what are now subtasks would be stories themselves, within epics, and would behave more like you expect from sprint to sprint.

[Rebeca Luna]

Hi Kelly, 

My main problem is more about underestimated tasks. So the sprint is always breaking and many cases like this happening. I know we need to improve estimation, velocity, etc.

But i'm struggling to move the story for next sprint with subtasks done which for me doesn't make sense once some subtasks were completed in the previous sprint.

We are still using the hours for estimate. I'm not sure if changing it to points would help us to complete the tasks.

[Kelly Albrecht]

Have you explored the Remaining estimate and time spent setting as can be seen in this article?

https://confluence.atlassian.com/jirasoftwarecloud/configuring-estimation-and-tracking-764478030.html 

[Rebeca Luna]

Yes, we use remaining estimate and time spent.

But my main point is how to organise Jira without loosing the track of what was done inside each sprint.

So if I complete 2 subtasks of the 3 I've planned, what should I do with this card? If I pushed the entire card to next sprint, I can see in the sprint report the card was moved, but that card had complete work done inside it.

So, how can I know if I am moving a card which I didn't even start or cards that have work already done inside it? 

[Rebeca Luna]

I think it's "complete work" X "work done".

I need to track what was complete but I need also to track what was done, even not finished.

[Kelly Albrecht]

 I usually go less granular and use the average points completed each sprint over time, to get a sense of a reasonable size to make future sprints. Some points don't land until the following sprint, but sometime you get extra points from the previous sprint. My experience is it averages out over time and, by communicating through the experience, the team improves on how much to commit to, which is more important than a few subtasks one way or the other on a single sprint.

Since I don't use it so granularly, this may be getting beyond my experience... I think tho, if you move the incomplete story from an ended sprint to the backlog, then when planning the next sprint, the estimate that adds up what you drag into it accounts for the logged time and uses the remaining estimate to show what's expected left to do.

This is how it seemed to me last time I was looking at this. Would that be the indication you are looking for, that there is some work done but some estimated time remaining for completion?

Might make sense for the team to reestimate the issue at this point in the planning anyway. I guess it depends on what you are trying to track.

Also, instead of a Story with three subtasks, could you just have them be three stories? Then when you complete two, and move the third, it would track how you want, right?

[Rebeca Luna]

I understand your points.

The thing you said "Also, instead of a Story with three subtasks, could you just have them be three stories? Then when you complete two, and move the third, it would track how you want, right?" is what we do at the moment, but it's lots of effort because we start with the card and let's suppose we had 6 bugs which are 6 subtasks. Then we fixed 5 of them but didn't have time for the last one. So, I need to clone the main task and move the bug to this new task, so we can keep the ones done in the previous sprint and move just the one not done to the new sprint. And this takes lots of time. This is my current problem.

[Nic Brough -Adaptavist-]

This is supposed to be difficult, because it's not the way you do Scrum.

The concept is that in a Scrum, you commit to delivering a specific set of stories within a sprint.  At the end of the sprint, the success criteria is very simple - either you completed a story if you did not.

You're not supposed to split a story because you didn't quite get all of it done.  You did not meet the commitment, so your velocity falls, and the story is punted, in whole, to the next sprint (or back to the backlog).

You're trying to measure partial success, which is not what Scrum is for.  What you are doing essentially destroys all the measurement and estimation you are supposed to gain from doing Scrum.

If you find you are doing this regularly, then the answer is to pick one or many of:

• Lowering the limit of what you commit to at the start of the sprint, so you don't do this as much
• Groom the stories better, splitting them up so that you are more likely to complete what you commit to
• Improve your estimations so that you stop underestimating stories
• Move to a more Kanban approach

[Kelly Albrecht]

@Rebeca Luna

let's suppose we had 6 bugs which are 6 subtasks

I'm suggesting to not have them be subtasks but to be their own independent issues.

[Mirek]

Yeah.. bugs vs. stories vs. scrum.. That is ongoing question how to deal with bugs. Here is a nice article from Scrum Alliance about that - https://www.scrumalliance.org/community/articles/2013/october/dealing-with-bugs-in-the-product-backlog

[Rebeca Luna]

According to the article they should be low effort and inside the sprint. I agree with this once we need to deliver the complete story. But the question is still on: if we don't finish all bugs or even a subtask during the sprint, should we migrate the whole story to next sprint and "loose" all work done inside the sprint? Or should I just move the bug/subtask?

[Nic Brough -Adaptavist-]

You can't move a sub-task type, it belongs with the parent.  So you'd have to create the bugs at the same level as story.  That will work, because if you don't complete them in this sprint, they will move to the next.  But it does give you the problem that you are now reporting that you are delivering stuff with known bugs.

[Rebeca Luna]

That's why what I do is call the story of part 1 of 2 and I clone the task so I can move the bug subtask to the task part 2 of 2 and this one can be delivered with no bugs. But it involves effort to do it instead of just move the entire story with all subtasks inside it. This is my problem.

[Kelly Albrecht]

Yeah, I wouldn't do any cloning or moving.

I also don't think it is a problem to "lose the work" in that sprint. The value come from completed stories. Subtasks are not meant to be that important.

If those issues are more important to you, then don't enter them as Subtasks, but instead make then separate, individual task, with no parent story. Then you will have none of the problems stated so far. 

[Mirek]

A story is issue that could be defined as a simple task or initiative that requires many tasks. You can break down stories into sub-tasks and thanks to that know what was done in a specific sprint. Overall when you close a sprint you will get a Sprint report where issue not resolved (because things might be overestimated, or simply not done) will be included (that it was in progress) and later will be moved to the next sprint automatically. There is not need to clone or doing other stuff to track progress. Doing this will introduce more confusion to your reports.

[Rebeca Luna]

The problem in doing this is: supposing I have one story with 3 subtasks where 2 are complete and 1 in progress, when I close the sprint, Jira is putting the story back to backlog with all subtasks inside it. But 2 of them were complete in the sprint before. I don't need to have them inside a new sprint again because looking to it, seems they were done in the current sprint when they don't and it confuses the estimates as well. This is my point. 

[Mirek]

@Rebeca LunaI would not say it is a problem, more like a way of handling tickets and breaking them down into so much small stories that they could be done in a sprint based on your team velocity. Sub-Tasks are more like for people assigned to them ability to track progress outside of initial estimation. Those should not be estimated using story points and not included in the report. No matter if a Story have subtasks or not it will be move to another spring, so from this perspective nothing change. Everything is for improvement. Overall Scrum idea is to improve in every sprint, be agile and react on faster, deliver more..