Is there an issue with moving to a previous status for any reason e.g. from a metrics perspective?

[Deleted user]

There is a column called Testing and if the test fails, shouldn't the card move back to development (aka In Progress)? 

Is there a best practice that speaks to cards moving right to left vs. left to right? Thank you

[Ste Wright · Accepted solution]

Hi @[deleted] 

I think this is down to how you define your metrics and ways of working.

In an ideal world, a card will move left-to-right - flowing forward through each status. But not every issue moves forward without error.

If testing fails - you could either:

• Leave the issue where it is - and have bugs or errors fixed as part of the testing process. You could also flag issues (right click > add flag) to show it has an impediment.
• Create a bug and link it to the story - showing that it is blocked from continuing due to an error in development, and track progression on the Bug instead.
• Move it back to "In Progress" if this is the best representation of issue fixing for your team

In turn I would define your metrics - so some example reports might be:

• Cumulative Flow Diagram: Do you want the statuses to show how much developers are working on (thus "In Progress") or to show issues which have flowed forward and gotten stuck at "In Testing"?
• Complete Issues: Are you most interested in burn-ups, burn-downs and velocity? If so, these rely on "done" issues so moving back a column isn't an issue.
• Time in Status: Is it important to know how much time an issue is with developers ("In Progress") vs with QA ("In Testing")? Or how many times an issue has been in a status, to measure the number of testing failures prior to a release? If yes, then moving back statuses would be beneficial to your reporting.

Jira is flexible, allowing your team to work the best way for you. I would decide what makes most sense within your reporting and ways of working :)

Ste

[Jack Brickey]

Hi Ricki, welcome to the Community. For the most part this is a subjective thing. However, let me share my thoughts.

First I am not a fan of moving an issue from development to test unless the testing is being done by the developer (unit testing). If it is a QA function being done by another person then I prefer to have a separate task linked to the development task. This keep ownership clean. If a failure occurs w/in the testing then a bug is opened for the dev team to address and again that bug is linked to the test issue. One key reason I prefer this approach is that it allows the dev team to declare when they are done and can 'release to QA' a feature/change.

If you do decide that passing off ownership of an issue is the way your team wants to go here are my thoughts:

1. reassign the issue from developer to tester when moving to Test status. Also, have a custom user picker field and record the developer into it when reassigning an issue to another person for testing. This can then be used when assigning the issue back to the developer
2. if a failure occurs then assign the issue back using the custom "developer" field from #1.
3. do a good job of recording the failure in a comment so that you have some history. This is where opening a separate bug is preferred as not is left to the imagination.
4. you might consider adding a "reopened" or "failed" status so that you can monitor for that and even run metrics on it down the road. 

hope that helps