Working multiple concurrent releases (versions) for a single project

[Mike Malone]

Summary: We have two separate teams for a project. We have a large set of issues for the project that will be worked concurrently by the two teams for twp separate releases. We currently use VersionOne and this is easy. You have a project backlog, you create release backlogs, move backlog items to the desired release backlog. For each release backlog create sprints, assign backlog items from the release backlog to sprints and start working. Issues we encountered trying to do this in Jira (suggestions for an easier solution welcome!): We created two Versions (releases) and assigned issues/stories (which contain sub-tasks) to the appropriate version. We created two scrum boards, one per version named appropriately. The filter for the boards was for all issues for the project. We created sprint 1 for version 1 board, set it's duration, moved issues to it. Looked good. We created sprint 1 for version 2 board, set it's duration, moved issues to it. Things got confusing. This changed the duration for sprint 1 on version 1 board. It appeared to be confusing the two sprints as issues from each showed up on the other. Did some searching and interpreted the results as each board needs to have unique issues on it's backlog to choose from. Suggestions were to use the "component" field for issues and filter the board on that. Didn't want to do that as there are many components, just two releases which the issues were already assigned to. So we wanted to use the version value in the board filter. Took awhile to find that the field name is fixVersion and that it was hidden and needed to make it visible and accessible. Did that and modified the filter for each board to only show issues with the appropriate fixVersion. That worked. Each board had unique issues and we were able to create sprints and put issues into them. However, when we clicked on an issue on the board, it could not show the sub-tasks as they were filtered by the new filter. So we had to manually edit each sub-task and assign them to a version. They are part of an issue/story so this should have been done automatically when the parent (story) was assigned. Is that a bug? So we got the two teams working on their separate releases. However, each time we want to add an issue to the project, to work it in a release we have to assign it to the version (that is ok) but we also have to manually add the version to each sub-task. Which is laborious. My suggestions: When a issue/story (backlog item) is dragged or assigned to a version (release), all sub-entities should inherit that property. When a sub-task is created for an issue/story that is assigned to a version, the sub-task should inherit that property. Any suggestions on an easier or better way to work concurrent releases for a single project? Thanks.

[Norman Abramovitz · Accepted solution]

It was hard to figure out what your question was. I think you just need to copy some fields from the parent to the child issue. This is not done automatically intentionaly, so you need to do it yourself in the workflow during the post-function processing. There are various ways to do it. I suggest you look into the marketplace.

JIRA Misc Worklfow Extensions and Script Runner are some examples that should work for you.