How to reuse features from earlier releases into upcoming rollouts?

Manish Keshari August 10, 2018

I have core foundation solution for which I created 76 Features and 150 user stories underneath and completed them in 8 sprints. Now this core is released as Release 1.0. In my upcoming regional rollout there will be 4 rollouts and each of the rollout will have say 80% features and userstories from the release 1.0 and 20% local features and user stories. I need to understand how can I reuse the earlier features and stories as those are not in the master backlog anymore (but are a part of relevant sprints under the already released release1.0)

1 answer

1 vote
Troy Spetz August 13, 2018

We use JIRA 7.10 server version.

 

If I understand the problem correctly, then I would suggest the following:

1. JIRA issues should not be 're-used'. Once the work is done, the issue remains closed. In this case, there is no point 'cloning' the closed JIRA issue, as this would imply the same work needs to be done a second time.

2. If you need to keep an 'inventory' of what features are in which release, it sounds like you will have to assign completed work to multiple FixVersions.

 

 

So, one possible scenario would be:

1. Core Release: Assigned to FixVersion: 1.0.

2. Local Release (contains Core Release FixVersion 1.0 features + local Region A features): Assigned to FixVersion: 1.0_Region_A.

- This means all of the work done Fixversion 1.0 will need to be double-tagged as Fixversion '1.0, 1.0_Region_A'.

- The work specifically for Region A will be single-tagged as '1.0_Region_A'. (This allows to differentiate between the core work and the local/regional work.)

 

 

Tagging like this will mean you can determine:

1. What is in the core release (features which will be in all of the local releases)?

2. What additional, different features were added to a specific, local release?

 

And yes, it means your FixVersion field could end up being very long for your core release features: They will need to be assigned to all the FixVersions for the local, Region release features as well.

Manish Keshari August 14, 2018

Thanks Troy it helps a lot 

Manish Keshari October 25, 2018

Hi Troy, 

 

I have a follow up question on your response.

After this when my story from core release is getting shown in the new/rollout/release, its status is still shown as 'Done'. Whereas, the story will need  to be worked by some developer for the new release. If I change its status to 'ToDo', my core release will be impacted. 

Is it a good idea to add a custom field for displaying the status of issue for current release say i add a field called as 'Status in current Release' and mark it as 'ToDo'?

With this I will also need to configure and add this field in the 'Version Details' section .

 

Please suggest

Troy Spetz October 26, 2018

Some follow-up comments:

1. I do not understand why a story which is 'Done' in the core release would not (also) be 'Done' in a specific, local release. The work should only be done once -- so the related JIRA issue status would be set to 'Done' only once. 

 

 

2. When we make a change in our trunk release, it is also pushed to our branch release (if we have opened a branch). This means the story in JIRA is closed once, but the related changes appear in up to 2 releases (trunk and branch).

Suggest an answer

Log in or Sign up to answer