With Many organizations now looking into implementation of a Scaled Agile process, I would like to suggest one approach which we have following in our organization:
Consider a process where a Program Increment (PI) happens every 3 months where all the features / demands are collected and then needs to be funneled down to multiple product teams for implementation. Each product team may work on their own pace having their own Sprints but they all eventually catch up to the Release train at the end of the 3 month cycle.
Let's take an example of three product teams getting feature requests from the PI.
We have created one Project (lets call this Master Project) to track activities on the Master train. i.e: the features.
3 separate projects - one for each team impacted. (Project(s) A,B and C)
So, total of 4 JIRA projects.
We have also created a new issue type called Demand - which we treat to be a level higher than an Epic.
The Master Project has a Kanban board to track all activities on the Master
Each team Project (A,B,C) have their independent Scrum boards.
All demands ( 3 month feature requests) are created on the Master Project which reflect on the Kanban board.
When a demand is created - the person creating the demand (usually business / vendors) may not know all the impacted products / projects. Creating a demand on the Master project takes out the confusions involved with analyzing the demand for each product. They just create the demand on the Master and it is up to the stake holders to identify the impact of the demand on individual products. Having a master project also allows to create and track tasks / stories that may need to be worked on the Master project rather than at the product level (These will usually be high level tasks - like budgeting, procurement, infrastructure, etc..
Each feature request is its own demand. When you have a Master project, you also have the capability to create versions for the project. You can create any number of versions ( Q4 2018, Q1 2019, etc...) on the Master project and add these versions to the demands that are impacted for each release. Since the demands are derived, the version is also derived to the story of the individual project. This way the Master and individual projects can be tracked individually or combined for any release.
A point to note here: We use Backlogs in Kanban. This allows us to prioritize the demands for each Release before work actually starts on the Project. During the prioritization is when Stories get crated for individual projects. All stake holders are involved in the Prioritization meeting. This happens once in 3 months and is called a PI - Program Increment on a Release train.
The Backlog in Kanban allows the use of drag&drop functionality for versions. i.e: you cn drag your demands to the version and then derive them to (how-many-ever) stories for (multiple) individual projects.
The Stakeholders of the Master Project (Product Owners and Scrum Masters from individual teams) can analyze their demands and Derive* (details below) Stories out of the Demand for their individual projects. These stories may be linked to Epics for that Project. (We use Epics to categorize functionality for the Project. Example: Login, Profile, Payment, etc..)
Workflow Implementations
These are some of the workflow conditions we have build into the workflows:
Derive: this is a workflow transition we have created on the Demand. When you click on the derive button - JIRA asks you which project you would like to derive to and once the project is chosen, it automatically creates a Story on the selected Project copying all the details and creates a link between the story and the demand with link type derives. (This is similar to the clone functionality - except that it allows to derived to a different project and different issue type). Once derived, all stories will be in the Open status.
We have built the capability to derive multiple times for any number of projects. This way the demand can be broken down to the granularity of 2 week sprints for each product's project.
The teams can independently prioritize and work on their stories.
If any team starts working on a derived story ( story is moved to the In Progress status), then the demand is automatically moved to the In Progress status.
The teams can also independently test and complete their stories.
Only when all linked stories are moved to the Close status, the demand is automatically moved to the Closed status. (This can also be done for the test status)
This way each team gets to work on their independent activity and the Master (Kanban) board is automatically maintained to reflect the status.
Few things to note:
All linked issues for a demand are configured to show on the cards on the Kanban board. This way the project management team can keep a track of activities within the demand easily.
We use multiple plugins to achieve this workflow:
* ScriptRunner for JIRA
* Jira Workflow Toolkit
* Jira Suite Utilities.
* We run on JIRA server
