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

[Thomas Jansen]

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.

[Michael Kinloch]

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.

[Thomas Jansen]

Micheal,

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

Did your approach work? 

[Michael Kinloch]

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.

[Thomas Jansen]

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.

[Michael Kinloch]

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.

[Ammar Hassan]

Hi @Michael Kinloch ,

Thanks for giving an overview of how to get from top to the bottom, but one question here. I don't see that we can create tasks (issue type = Task) under a story like in a hierarchy, though we can link a Tasks to Stories.

When you say Task, do you mean sub-tasks (issue type = Sub-task) under stories to track the actual technical work needs to be done by the team?

Also, from your experience, if you can guide us how Tasks (issue type = Task) is being used in a software project. Though Tasks comes under Epics, but at the same level as story. What you recommend if one should follow which approach;

• Epic
  • Story
    • Sub-Task

OR

• Epic
  • Task
    • Sub-Task

OR

Combination of both? 

[Michael Kinloch]

Hi,

It would be a combination of both.  Typically your stories are your placeholders for a conversation and relate to a piece of business functionality.  Tasks tend to be more technical in nature.

Mike.

[Ammar Hassan]

Thanks @Michael Kinloch, We are finally going with approach as you said. 

[Eran Malovany]

@Michael Kinloch 

Sorry to jump into so late :)
was looking for something and find out this post...

when you mention above a combination of both, what do you exactly mean, do you use story to define "end user functionality" and link to the story multiple technical tasks? or you use Sub-tasks that comes out of the box to split the stories to multiple technical sub tasks.

trying to find the best match, so multiple teams on the same project can work on the same User story but still be able to see all technical work in the backlog, estimate it and drag to the sprint of the relevant development team...

Thanks so much !

Eran.