Tracking issue after sprint for deployment

[Tim Vijgen]

Hi,

We have a sprint development cycle of ToDo, Developing, Testing and Done. When the issue is done it is marked as resolved and ready for deployment.

I would like to get some ideas on how people manage the deployment process in Jira Agile. At the moment I have the following situation:

- A sprint can contain issues that will be deployed in different releases.

- We have a process of Resolved(ToDo), Testing server, Production server(Done/Closed)

Regards,

Tim

[Tim Vijgen · Accepted solution]

Hi Benito,

This is correct.

I created a workflow ToDo -> Developing -> Testing -> Resolved -> Testing server -> Production server(Closed) but I have the following problem:

Sprint (ToDo -> Developing -> Testing -> Resolved)

Kanban (Resolved -> Testing server -> Production server(Closed))

The sprint and kanban share the same "Resolved" status. This is causing trouble if the issue is moved from "resolved" to "testing server" before the sprint is completed. The issue is then not included in the sprint result and story points are not included.

Is there an option of triggering a new status for "resolved" issues when an sprint is marked as completed?

Regards,

Tim

[Torsten Mohrbach]

Hi Tim! The 'triggering' of course would only work, if deployment takes place AFTER the sprint completion. The question remains what to do, if a workflow with the need for timely deployments is in effect. Any suggestions on that anyone?

[Benito Picarelli]

Hello Tim!

If I understood you correctly, you are using the scrum to create your backlog and plan your sprint, and then throw the sprint onto the kanban board to manage it's execution.
If I got it right, I'd say this is very good way to handle things, since you can use the quick (kinda non-stop) execution of kanban while doing the whole control of the bigger picture on scrum.

Cheers!

Benito Picarelli

[Benito Picarelli]

Hello Tim!

If I understood you correctly, you are using the scrum to create your backlog and plan your sprint, and then throw the sprint onto the kanban board to manage it's execution.
If I got it right, I'd say this is very good way to handle things, since you can use the quick (kinda non-stop) execution of kanban while doing the whole control of the bigger picture on scrum.

Cheers!

Benito Picarelli