How to let multiple development teams use User Stories between them?

Fredrik Svendsen

Hi,

We're defining Epics as bigger deliveries, which consists of multiple User Stories linked to an Epic. This is perfectly fine, as the developers can assign Sub-tasks to the individual User Stories.

I get that if a Story needs multiple teams working on it, it might need to be slightly smaller but given a Story (for one function) needs input from two or more teams, how can you define a small enough Story? I'm struggling a bit with it.

To show my current workflow with is basic;

However, once a User Story needs additional input from another development team, how can I successfully create a good workflow so that both development teams won't (necessarily) close an User Story prematurely before both teams have done the work?

Ste Wright

Hi @Fredrik Svendsen 

I would try to keep a Story assigned to one team.

I look at it like this in standard Jira:

• Epic: This is a collection of user stories that, together, deliver a piece of functionality. Multiple teams might work on one Epic.
  • This might represent a product or a release - but FixVersions are another good method to manage releases if this is the case!
• Stories: Small pieces of functionality that can be taken from creation to completion, based on a user's needs.
• Sub-Tasks: Technical tasks which together allow for delivery of a Story.

If a story needs two teams working on it concurrently, you might want to consider whether it is bigger than one story.

-----------------

But - if this is how your team's interact, you could consider:

• User Picker Fields: Have a custom user picker, to identify where additional users are required for completion of a Story. Assignee might be who is working on the issue, whilst a custom field "Reviewer" might be who is needed before completion of the Story.
  • This could be a different field - for example a Group Picker and each team could be a Group? 
• Linked Issues: If there are two stories (one for each team) - link them together to show where one issue might be dependent on another. Eg. Link Issue 1 to Issue 2, showing Issue 1 blocks delivery of Issue 2.
• Sub-Tasks: If only one Story, create a Sub-Task for each component of the build, assigning them to the right user (regardless of team).
• Conditions: Utilise these to limit who or when an issue can be closed - for example:
  • User: To reduce the risk of issues being prematurely closed, limit who can close an issue - for example, only allow the Assignee or the Reviewer (custom field) to close the issue.
  • Linked Issues: You could limit the closure of an issue if it has an open linked issue in the type of "blocks". For this you'd need an app, such as Jira Misc Workflow Extensions
  • Sub-Tasks: Use a sub-task blocking condition, to stop the Story being closed until all Sub-Tasks are

-----------------

Note: Whilst custom fields are available in Next-Gen projects, workflow Conditions are only in Classic Projects. If this is for a Next-Gen project - you might need to consider status reversals using Automation for Jira instead.

Let us know if this is Next-Gen

Ste