Manage business demand (ie Features/Epics) flow across teams

Question

Hi Forum

We have a single business demand pipeline where Feature Requests (represented as Epics in Jira) go through a few hoops before being approved or rejected. Approved Features then get assigned to one of 3 build teams. How best to manage this in Jira teams based projects?

Here are my initial thoughts: I am thinking of creating 4 (kanban) projects. One to track the initial requests (as Epics) through to approval or rejection. As well as a Waiting for Approval column, this board will include 4 other columns: Rejected and 3 Approved columns, one for each of the 3 build teams. When an epic lands in an approved column, automation will move it to the corresponding project. Is this do able? More important - does it make sense. 
note: we could have a company project and use components, but each team will eventually have tens of epics over time and I think this may overrun a component based solution? Would appreciate feedback.

thanks

Kevin

Bill Sheboy · Accepted Answer

Hi @Kevin hankinson

In my opinion, "yes it is doable and yes it makes sense".  Showing the complete value stream at this scale could help with demand/capacity/readiness conversations.  For example...

What if your "business level" board kept the work items on it rather than moving them and instead the automation cloned them to the target team's project?  That would provide visibility of what was sent to teams and if there are business readiness aspects (e.g. marketing, training, release notifications, measurement of results in production, etc.) they could be managed from your business board.

Kind regards,
Bill

Ste Wright · Accepted Answer

Hi @Kevin hankinson

This sounds like a good solution to me - a few things I'd consider...

* How do requests get into the pipeline project? If all requests come from Jira users, a normal software project works fine. If not, and it could be external users/customers - you might consider using a Jira Service Management project.
* Does the pipeline project need to track work end-to-end? It might be beneficial to either track the Feature Request all the way to delivery (i.e even after team assignment), or link it to the team's largest piece of work (Initiative/Feature/Epic) after approval.
* Is a piece of work assigned to one team, or multiple teams? This might change your perspective on how to identify team involvement.

If I was to design this, this is how I'd do it...

Request Project:

* Decide if the Workflow will track just to approval, or through to delivery
* Create an appropriate Workflow based on the scenario* I'd use resolutions to show Approval/Rejection, if request closes (see below)

* Have a field to visualise which team is involved. I'd not use components as these are not cross-Project, but you could use Team (from Advanced Roadmaps), or use a custom field. This can be used as a condition in Automation.
* When a request is ready for a team to work on, there's a few options...* Move the request into the relevant team project using automation, based on the field
* Close the request as approved, and auto-create a new Epic for tracking delivery. I'd link the request through to the Epic automatically for traceability
* If the request is going to track through to delivery, you could also create Epic(s) in the team project(s), and keep the request open.* In this instance I'd probably consider making the request a parent Issue Type above Epic, such as Initiative (using the Issue Hierarchy from Advanced Roadmaps) - assuming this fit into the work model

Team Projects:

* There's options here, but I think for your scenario I'd have a Project per team. This is assuming teams own specific requests, including all releases. This option keeps the data all together nicely.
* Use Company-managed Projects - to make it easier to have cross-Project hierarchies/issue linking. It's also then possible to use Advanced Roadmaps where needed.

Let us know what you think of the above! If you need any more specific instructions for automations, etc - just let us know.

Ste