How can I best keep track of what issues are actually released while working on multiple versions simultaneously?

Richard Berry

The workflow my team and I are currently using goes as follows: Open > In Progress > Testing > Committed > Released

This has worked for while the work we were doing was relatively simple and all committed work could be release at the end of a sprint. However what we are finding now is that as our work grows in complexity, we cannot always release every Improvement described in a sprint because it may be dependent on another issue in a later sprint.

This means that in order to close a sprint, we are now having to move all of the un-released issues to the next sprint which is messing up our tracking.

I have considered changing the workflow so that issues are resolved at the Committed stage, all work on that specific item effectively being complete, but then I'd lose track of which issues have or haven't actually been released.

Is there a way in JIRA to display, log, or somehow keep track of whether issues have been released or not outside the in-sprint workflow?

Any help would be greatly appreciated!

Chris Dunne

I would use the built-in Release functionality for this. 

Suppose you have Release 1.1 set up for your project. After the state Committed you could have two states - Released and On Hold. When you move to Released you could require the user to choose a Fix Version and set the resolution reason. When you move to On Hold you can set the resolution reason and ensure the Fix Version is cleared (there a post functions in JIRA Suite Utilities to do this).

Then in the release hub you can see exactly what was in each release. And from the backlog you can move items from version to version (provided they are not closed).

I tested this using the default workflow and it seems to work fine.

Chris