Best practice for using Jira Issues (User Stories and Sub-Tasks) on multiple Jira Projects

We are creating a set of user stories that are being used by the development team to create the system. Our software is being developed for the Salesforce platform so when it is installed, it must be "configured" to meet the business specific needs which differ from company to company so, therefore, we will want to reuse the user stories on many Jira Projects.

The user stories that are developed for initial use on the development are very similar to the user stories that are used when the application is configured for a customer.

What is the best way to clone, duplicate, etc the user stories and sub-tasks for reuse on other Jira Projects?

What is the best (most efficient) way to capture the user stories and sub-tasks for development while also capturing the user stories and sub-tasks for a customer project configuration.

1 comment

I'm currently facing exactly the same problem.

I've just designed a hierarchy enabling us to maintain a seperate repository of Epics and stories to be reused across customer projects.

 

Will be testing it out next week to see if it's actually viable.  8f it works I will post the design.

Interested to see what comments you get back here to see if anyone else has solved this problem before.

 

Micheal,

I havent seen where anyone has been able to solve this use case.

Did your approach work? 

Hi Thomas,  got sidetracked last week at work due to some other priority issues.  Will be picking it up again this week to implement the approach and confirm it works.  I'm putting together a work flow in microsoft vision too to map out how it would work.  Once I've confirmed I will share the flow. 

 

Mike.

Hi Michael,

Did your approach work to solve this use case? I am still looking for someone who was able to solve for this problem.

Hi,  We have tried a couple of approaches which will work but we are using the simplest one.

We define a version per release as normal.  We define our Epics with enough detail in the descriptions to form a feature catalogue and link them to the version.  We create high level stories using INVEST at the level adequate for reuse by other projects and link them to the Epics.  At this point we have a very standard structure.  There is a Scrum board used to manage this master backlog by the product owner and the team.

We then have separate Scrum boards for the teams building the core product using the above (number of boards depends in number of teams you have ).  All of the boards mentioned so far use the same single project. On the team boards the teams breakdown the stories as they see fit and create them as tasks in backlog refinement sessions.  These tasks won't be reused so it doesn't matter how they do this but the tasks are linked to the parent stories to enable us to have traceability.  Each team starts their sprint using their own boards and works to completion.

We create a script in Jira so that when a team task is moved to in progress the corresponding story is also moved to in progress automatically.  When a sprint ends the team check their definition of done and close their tasks.  They also manually close the linked story if all tasks linked to it are completed.  This is our sprint review.

Any linked stories not completed in that particular version are moved back to the main backlog (see first paragraph) and unlinked from the version (as they weren't completed in the version).   Any incomplete tasks are also moved back to the backlog but not removed from the version.  The reason for this is we want to maintain a version, Epic and Sprint progress history.  Removing story is ok as it's really just a high level placeholder.

This leaves you with a version, with any Epics completed or partially completed, plus any completed stories, plus any competed or uncompleted tasks all linked to each other.

Future projects can now simply query for all these issue types for a version that has been finished and filter out the tasks giving you a reusable set to export and import into the next project.

 

Hope this makes sense.  It's always difficult trying to explain in writteformat but the process works well and only uses core Jira functionality (apart from one custom script to put stories to in progress).  The discipline is in the process of managing your backlog not Jira.

Comment

Log in or Join to comment
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,110 views 13 19
Join discussion

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot