Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Implementing Scaled Agile in JIRA - One way to do it

Gundlupet Sreenidhi
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Oct 21, 2018

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


1 comment

@Gundlupet Sreenidhi - I found you post very interesting as I am trying to model Jira for SAFe and we had several iterations of changes with limited level of success.   I sort of understand you setup but I'm also curious on the agile practices that this Jira configuration supports.  How do you estimate the Demand work in the Master?  How do manage WIP in the Master Kanban and therefore manage capacity vs demand?  Do you follow Scrum for the Team boards or Kanban?  Also, would you be open to Webex chat?


Log in or Sign up to comment