I'm curious to know if you can have multiple statuses in the Done (far right) column that do not contribute towards the next Sprint completion metrics. In this example, such as Passed QA, In UAT, Regression, Ready to Deploy, Shipped & Cancelled) are all "Done" in the Sprint board, but continue to appear in future Sprint reports as completed issues until they are Shipped or cancelled.
Does anyone know of a workaround or have a suggestion to mange the statuses after The Sprint work is complete, from Passed QA in UAT stage?
No because "done" means "done". These status you have mentioned are mostly probably not done, so the way to handle it is not put them in the done column. Or if they are done for the team, they should be in the done column.
You need to decide what "done" really is for the team using the board and then make your right-hand column match it.
For your case, there's probably a better option than saying all those status are just "done". A board is supposed to represent the work for a team. It sounds like you have a process that your team is only partly responsible for. That's not Agile, the team is supposed to be able to deliver items in full, but in real life, it often doesn't work that way, and when it doesn't, you should re-define the board so that it works for the team, not try to show everything.
Long story short, your board should simply ignore issues that are out of the control of your team. Your "done" column should have Cancelled and whatever the status is when an issue has been completed by tge devlopment team. Then you do not even map Passed QA, in UAT, Regression, Ready to deploy or Shipped in the board - they're irrelevant to your team, so you don't need them on the board.
Why not have add a custom field for what type of done you want and still keep one DONE status? With a quick filter you can drill down to any combination of the DONE flavors.
Wouldn't that make the board less complicated and metrics easier?
When I have had to provide reports it's frequently like "What's done?" for the entire Production Team then deeper into where each team may be (the specific DONE choices). It's usually easier to divide one bucket vs combining different buckets properly.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event