Adding release management workflow after a sprint

[Chris DeAntonio]

My scrum team currently has a sprint board built and working well with the last status being Done.  Now, we want to take the next step and build out our release management workflow, which is independent of a sprint.  But we want the same user stories to flow from the sprint workflow into the release management workflow.  

The Release Management workflow would be something simple like: "QA Testing -> UAT -> Released" and this would be tracked in a separate Kanban board.

To make these additional steps in the workflow, I am thinking I need to change out our scrum board's Done status with something like "Ready for QA" as the last status and not set a Resolution until the story reaches Released.

So, in total, the user story workflow would go:

To-Do->In Progress->Feature Testing-> Ready for QA (end of sprint)->QA Testing->UAT->Released

My main concern is just around reporting:

If I swap out the last status in my scrum board from Done status and replace it with the "Ready for QA" status that doesn't set a resolution, will this impact reporting in any negative way?   Will this impact sprint reports, epic burndowns, etc.?  Or do those reports just key off of the last column in the scrum board to determine what has been completed?

Are there any best practices or other considerations anyone can share on this scenario?

[Jonny Adams]

@Chris DeAntonio Adding those additional statuses can affect your sprint reporting. In my experience, if an issue isn't in a Done type status then you only have the option of moving it to the next sprint or backlog when you complete the current sprint. Also, adding statuses into you sprint board will delay closing the sprint and can skew your developer's work report.

I think you may want to keep the development sprint and release workflow split onto separate boards. It would keep development and QA spaces clean and help hone your sprint estimating. You could keep your workflow as stated and make "Ready for QA (end of sprint)->QA Testing->UAT->Released" statuses all of the type Done. Then you could have your sprint board with To-Do->In Progress->Feature Testing-> Ready for QA (end of sprint) and a Release board with Ready for QA (end of sprint)->QA Testing->UAT->Released statuses. That way at any point in time your QA team can view their QA board and progress issues through the release workflow and when you close your sprint, Jira will not argue about issues not being "Done".

[Dominika Phillips-Blackburn]

I have this exact problem, we do UAT testing outside of sprint. I understand from your suggested solution that you would have 1 board for developer/QA work and another for UAT. Only problem is that the user stories would need to be bulk migrated everytime from one board to another to make sure they were UAT tested after the developer work is done, and that would be a cumbersome process. Any suggestions on how to make it work? 

[Chris DeAntonio]

Yup...I solved this by the statuses on by board.  This was over a year ago, but if I remember correctly, I did this:

- On the developer / QA board I made the right-most status the first status on the UAT board.

- So, when QA is finished, the items are moved to the right and then they will show up on your UAT board which has that same status in the left-most column.

Initially, I feared that this wouldn't make the items show as "Done" on the Dev board, but the only thing that controls that is the first that items are put in the right-most column.  That triggers a done status.  Give that a try.

[Dominika Phillips-Blackburn]

Thanks for responding.

And just to be clear - you are talking the Kanban board not a project board. 

Also did you have to tinker with the ticket workflow?