Ready for release Vs done

[Andrea Smart]

Is there a way to split the done column into 2. A done part for tickets that are complete and a ready for release part for tickets that still require testing but essentially the work is done? 

We currently have a ready for release column where "dev completed" work lives but it's not done done as it hasn't been through regression testing yet and regression testing happens after all sprints are complete within a release cycle (currently 4 sprints per release).

[Jack Brickey · Accepted solution]

You can have two statuses 'done' and 'done done'. However, for scrum boards only the right most column will be processed as done. All other issues including those in 'done' will go back to backlog on completion of sprint.

[James Chan]

Hi @Jack Brickey - I'm curious to know what's the best practice to show the items that are "releasable" (aka dev completed, QA/UAT'ed) in the burndown chart.... and how you would use the board to present what's releasable (done) and released (done done).

Would you map both 'done' and 'done done' status in the right most column? Or leave the 'done done' status as unmapped?

FYI @Andrea Smart 

[Jack Brickey]

If you wish to manage deployment separate from development complete issues and you want to leverage scrum for development you might wish to consider two boards.

• Development (scrum) - with To Do - In Progress - Ready for Deployment 
• Deployment (Kanban) - with Ready for Deployment - Deployed

this allows you to have the dev team separate from the deployment team/decisions

of course this really depends on understanding your process and how are you and your team work.

[Alex Rohrs]

I really like the concept of separating development activities from deployment activities with 2 separate boards. 

How would you set it up to be able to transition a ticket from the Done, or Ready for Deployment, state on a team board to the Ready for Deployment state on a shared Kanban board in a scenario where you have 3 team boards and a shared deployment Kanban?

[Jack Brickey]

Hi @Alex Rohrs , I'm not sure I fully understand you're use case. If you wouldn't mind could you further detail what your workflow looks like and how the various teams would use the workflow? Further which boards apply to each team?

[Alex Rohrs]

Hi @Jack Brickey , thank you for your quick response and I apologize for the lack of clarity in my question.

I am working with a new company that is struggling with visibility into team velocity and sprint health. It is a small group with 3 scrum teams that use the same workflow in Jira. It is quickly become apparent to me that the main challenge that they are facing is that stories are not considered 'Done' until they have been deployed to production but they do not deploy to production on the same cadence as their sprints so a given story can stay open on a board for 2 or 3 sprints even though it has been validated and met a team level DoD.

The current workflow that each team uses consists of 3 development states (In-Progress - PR Review - Ready for QA) and 2 QA states (QA In-Progress - Ready for Production) and then there is a state for DONE once it has been deployed. Ideally 'Ready for Production' would be considered Done at the team level with stories in that state moving to the Deployment Kanban.

I would like to set up a workflow for them where the teams can close stories within the sprint, assuming they meet the team level DoD, then the closed stories can transition to a Deployment Kanban board with 'Ready to Deploy' and 'Deployed to Production' states. Ideally the 3 separate scrum boards could feed into a single deployment Kanban board.

Thank you for your help!

[Jack Brickey]

So I would consider the following solution

full workflow...

TO DO --> IN PROGRESS -- > READY FOR QA --> QA IN PROGRESS -- READY FOR PRODUCTION --> DEPLOYED

Three boards...

DEV (scrum): TO DO --> IN PROGRESS -- > READY FOR QA

QA (Kanban): READY FOR QA --> QA IN PROGRESS -- READY FOR PRODUCTION

DEPLOY (Kanban): READY FOR PRODUCTION -- DEPLOYED

[Alex Rohrs]

That makes sense and is aligned with what I was thinking. My question, however, is how to transition tickets between the boards.

I would like to be able to close a story (done) at the READY FOR PRODUCTION state at the team level then transition the ticket to the Release Kanban board.

I would like to be able to track sprint level burndown (IN-PROGRESS through READY FOR PRODUCTION) and CFD and Cycle Time (IN-PROGRESS through DEPLOYED).

[Jack Brickey]

You don't really transition them to the board per se. Rather you simply transition issues to the appropriate status and you ensure that your boards have the appropriate status mapping.  In my above response the statuses represent the columns beach board. So for example, in the development board I would complete the sprint and all issues in the ready for QA (last column on DEV board) would be considered DEV complete. The QA board would have Ready for QA as the first column and the QA team would transition those to QA in progress when ready to test. I hope this makes sense?

[Jack Brickey]

Yes the last column in the equates to done for each board. Regarding cycle time on the board what exactly do you mean? How do you want to analyze that data? In a scrum board you have a fixed sprint cycle, such as two weeks. So that is easy to contemplate the cycle time. It gets a little more difficult to measure the time between entering/leaving statuses at least OOTB.

[Alex Rohrs]

On top of tracking the velocity at the sprint level, which your suggested workflow solves, I am also looking for visibility into total cycle time for a given ticket. The time from when the ticket first enters the workflow until it is ultimately deployed to production.

[Jack Brickey]

I think you're going to want to either look at add-ons for this or consider simply leveraging Excel with the free extension that leads Jira directly allowing you to run a query right within excel. This will allow you to analyze the data you want.

[David Hawkins]

Thank you for the discussion.  I am in a similar situation and have a question about using the Jira reports in this scenario.  How do I configure Jira to use the "ready for QA" state, in this example, as done for the Burndown and Velocity charts?

Thank you

[Alex Rohrs]

I think that makes sense. So the last column on each board represents 'Done', correct? In that scenario would I be able to track a ticket's total cycle time through all 3 boards?