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 · Accepted solution]

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

[Fredrik Svendsen]

Thank you, Stephen, for the in-depth answer.

The reason behind my inquiry formed from a discussion regarding a specific User Story, describing the piece of functionality from a user's perspective, that seemed to need additional work done by another team focusing on other aspects of the tech-stack.

For the sake of illustration, an example akin towards the two-team-problem could be;
"As a customer with a credit product, I need to have the option to block my product for further use, so that I can easily prevent mishandling of my credit"

Here, one team (A) would work towards the back-end integration to abruptly stop further use of the said product from the CMS (Card Management System), whilst another team (B) would work on any 2nd. level integration and communication concurrently across multiple channels to then also get the action concurrently across. Because of the way the domains and channels are set up, you can't solve this action ("blocking") by only one API-call which would reside within one particular team (A). You, therefore, need two teams to work on the functional requirement described above but solved from their own domains respectively (CMS and 2nd. integration layer).

I'm aware that it would obviously be solved with less hierarchy and siloed landscape within the development teams, but hey, that's how it is and I'm looking at ways to mitigate the risk of 1) doing double-work, 2) mishaps and concurrent faults across multiple value chains, and 3) communication breakdown from a Delivery Lead's perspective to actually get stuff through the pipeline.

I will play a bit around with the above suggestion to see what fits our needs!

Hope it gave some more input!