Several workflow steps with category done

[Torsten Waldeck]

Hello,

we have the three workflow steps for finished tickets.

• Completed (developed and successful tested tickets)
• Ready4release
• Done (released tickets)

The workflow steps Completed and Ready4release are currently mapped to the category Progress. This leads to the effect that we need to build a new release before we can close a sprint. I want to decouple the sprint cycles from the release building (release on demand) by changing the category to Done for the workflow steps Completed and Ready4release.

It is running project.

Can this change have any side-effects which cannot be removed anymore?

Thanks for your help!

Torsten

[John Funk · Accepted solution]

Hi Torsten - Welcome to the Atlassian Community!

Changing the Status Category of those statuses to a Done category should be fine. Just check the post functions on the transitions to each of those statuses to then set the Resolution field value.

Finally, just realize that it is not the status category of Done that closes the Sprint - it just that the status is in the final column of the Sprint board. So if you move those to a Done status category and you want the Sprint to treat those as closed, then make sure you put those statuses in the final column on the right in your Board settings. 

[Torsten Waldeck]

Hi John!

Thanks for your answer.

We have separate columns for completed and ready4release in the sprint board. When I close the sprint, tickets with the status completed or ready4release will be still moved to the next sprint. Changing the category to done has no effect on this.

Instead, I have to move Completed and Ready4release to the final column in the sprint board but can leave the category on Progress.

Did I understand that correctly?

[Bill Sheboy]

Hi @Torsten Waldeck  -- Welcome to the Atlassian Community!

I agree with John's suggestions on "how-to", and...pausing to ask follow-up questions.

You note wanting to decouple development during sprints from release building. So do you want:

1. To have two separate processes, with sprints for delivery and more kanban-like pull for releases, or...
2. Do you just want to keep one process to see work, from start to production, for reporting, measurement, etc.?

For the first option, you could create separate release-management tickets, linked to release content tickets, and put the release items on a separate board.

For the second option, you could keep one board, and accept that it takes longer than a sprint for releases to be developed and released to production.  That might incentivize smaller releases.

Best regards,

Bill

[John Funk]

@Torsten Waldeck  - Basically, yes to your question. 

AND, you should definitely consider @Bill Sheboy 's questions in the process of a final decision. 

[JudeLabs]

It seems that there is one workflow being used with multiple DONE states. And then you can configure board 1 to show up to the first DONE state,  and then board 2 can be configured to show the states from where board 1 left off to the last done.  This will allow you to use one workflow,  but show status that things are moving and closing in a sprint,  even though you only have one story.

How does this affect overall metrics that Jira gathers?  Does velocity and version completion estimation reports still work right?