Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How to I structure a project with multiple live minor versions across multiple major releases?

I'm in the process of migrating from our legacy system into JIRA and we need to maintain our project structure to minimise disruption to the teams and to clients. My problem is this:

 

We have multiple release streams of which there are multiple live minor versions in the wild at any one time. An issue may arise which affects all the currently supported streams. I need to be able to highlight that issue as affecting those streams, have it visible in each stream's backlog and allocate it to a specific release version below each stream as those releases become realised.

 

eg. 

 

Project

|_ Streams

      |_ 1.0

           | 1.0.1

           | 1.0.2 (last release out the door for this stream)

      |_ 2.0

           | 2.0.1

           | 2.0.2 (back patches being merged for release. scope already set)

      |_ 3.0

           | 3.0.1

           | 3.0.2 (under active development)

 

Defect X is found and it affects the newest version of all 3 streams. 

We can expand our scope for 3.0.2 to include the fix.

We cannot expand our scope for 2.0.2 so it will go into 2.0.n (2.0. something but must show up in the 2.0 backlog)

We are not aiming to release another 1.0 stream release but if we must for a critical bug, we will also factor this fix in as it's low risk so this will be 1.0.n (1.0. something and must be in the 1.0 backlog)

 

How do I structure my tickets and kanbans to demonstrate this?

I don't want 3 tickets because there is only 1 bug and the single fix will get merged across all three streams so only 1 git commit.

I could use fixVersion for my final release versions of each stream but how do I track the concept of Stream 2.0 for example?

 

Effectively, we need a single backlog view of "all tickets not under development"

Another for "These tickets affect the 1.0 stream but aren't tied to a release"

Another for the 2.0 stream and another for the 3.0 stream.

Moving a ticket that shows up in 1 stream to a release scope and assigning it as "in progress" shouldn't make it disappear from the other backlogs.

 

For reference, we are a legacy waterfall style project and unlikely to reorganise into a scrum & sprint based release cycle. We are using JIRA v8.11

 

Thanks in advance.

1 answer

Hi Jonathan, in my experience, out-of-the-box Jira doesn't really handle this effectively.  Our use case is similar to yours, and we've addressed it very successfully using Structure for Jira. I recommend it very highly!

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Posted in Jira Software

Presenting the "Best of 2020" Jira Software roundup!

Catch up with Atlassian Product Managers in our 2020 Demo Den round-up! From Advanced Roadmaps to Code in Jira to Next-Gen Workflows, check out the videos below to help up-level your work in the new ...

7,018 views 8 28
Join discussion

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you