Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Issue bouncebacks occur when a task or project issue reappears after being marked as resolved. This usually signals a quality problem, such as an incomplete fix, a missed dependency, or an unresolved bug that requires reworkticket moves back to a status that it has already been in at least once before. This indicates that the criteria for progressing from one status to another are not well understood by the team, the specific work being done is poorly defined, or the team is juggling too many things at a time.

...

Description

Issue bouncebacks refer to instances where an issue that was previously closed or resolved resurfaces later, often indicating that the original resolution was incomplete or ineffectivemoves back to a status that it has already been in at least once before. When issues bounce back, the team suffers several impacts to efficiency:

  • The person who prematurely moved the ticket forward and the person who bounced the issue back will both have to context switch to pick this work back up as it moves forward through the process once more.

  • After the required changes are made, any tests or reviews that were done previously will need to be repeated.

  • If bouncebacks are common, it can be impossible for the team to estimate their capacity accurately, making planning and hitting deadlines very difficult.

Issue bouncebacks often require rework and additional effort, or uncover requirements that were previously unknown, which can lead to project delays, added resource strain, and potential quality issues. Monitoring and analyzing bouncebacks provides valuable insights into the efficiency of your issue resolution process and helps identify opportunities for improvement.

...

How is Issue Bounceback Calculated?

To calculate issue bouncebacks, you need to track issues through Allstacks calculates bouncebacks in the following stepsmanner:

  1. Track the initial resolution: Monitor when an issue is marked as resolved or closed.

  2. Identify when the issue reappears: Record instances when the same issue resurfaces after being closed, indicating it was not fully resolved.

  3. Count and analyze bouncebacks: Calculate the number or percentage of issues that have been marked as resolved but then returned to a previous state (such as "In Progress" or "In Review").

...

  1. Whenever an issue visits a state it has been in previously, it will be counted as 1 bounceback.

  2. If an issue visits multiple states that it has been in previously, each of those states will add to the bounceback count.

  3. If an issue bounces back several process stages at one time, for example bouncing back from QA to To Do, and then moves forward through the process, going from To Do to In Progress to Code Review to QA, each of those statuses it re-visits along the way will add to the bounceback count, even though it’s moving forward through the process now. This allows you to see the impact of tickets that require more significant rework vs tickets that only need to go back one step to get back on track.

...

Questions You Can Answer with Issue Bounceback Data

...