Track tickets rolled over to a new sprint

[adam_gill]

Hi

I want to be able to track tickets that do not get started in a sprint, and therefore get moved into the next sprint (and possibly on again).

I'm trying to use this as a way of tracking efficiency in teams as to "how distracted" they become during a sprint - i.e. do many tickets get left behind because other things crop up during the sprint. My ideal is I have a list of projects and a metric against each for the last x sprints on average number of tickets "left behind".

Of course a ticket may have been left as ToDo in Sprint 1 and become completed in Sprint2 - but I'd still want that to appear in the report.

Is this possible - I couldn't find people doing this.

Thanks in advance - Adam

[G subramanyam]

Hi @adam_gill welcome to the Atlassian community.

I really wonder in the first place why are team distracted and not able to understand the Sprint goal and scope!!

Coming to your query, when the Sprint is ended the incomplete Jira issues will roll over to the next Sprint or to the backlog as per your board set up. If rolled to the next Sprint, then you may see the list in the "Sprint report". This you can include in your reporting dashboard.

You may have to use the JQL (documentation)  which will help you with specifics of the issue roll overs that support your reportings.

[cwhite2]

To answer a comment from above... sometimes the Stakeholders find bugs and those are prioritized over upcoming ticket tasks or estimations are incorrect, illness, etc.  So life happens.

What we have found effective is if a ticket can be partially completed, we re-estimate (for example a bug ticket has happened mid-sprint) and we reduce points for the actual sprint work we can complete, then we clone the ticket and have it in the next sprint.

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

This isn't something that's easily implemented in Jira Software.

I think it is because it is missing one of the points of doing Scrum.  When you are doing Scrum, you should be constantly looking at what is going wrong and why you are failing to deliver what you said you would.

If nothing else, when you end the current sprint, the team should be looking at each issue that is in the sprint and not done and explaining to their scrum master and product owner why it did not get done so that your processes can be improved in a way to prevent it happening again.

If you're Agile, you don't need a report on things being pushed into the next sprint, your team just looks at the board at the end of the sprint and tries to fix what stopped them from completing any not-done issues.

Remember that the aim of a sprint is always to complete all the issues that the team says they can do during the sprint - roll-over should be a rare occurrence and ideally only explained by "lost a team member for a while during the sprint for unforeseen reasons like being ill or having a family issue". 

If you're regularly rolling issues over into new sprints, you have a problem with the way your teams are working (which could be anything, although the usual problems are usually poor estimation, team being micromanaged, the boss pretending to be Agile when they really haven't got a clue what it is, failed process in other teams that your work depends on, or just the team not understanding Scrum).  You should fix that, not just try to report on it.