How to organize multiple Scrum teams and feature planning?

[Chris]

Hi all,

I already used the search function, trying to find an answer to my question but so far I didn't find a good solution. Hopefully, one of you can help me :-)

We have a project with 5 scrum teams, each of them having its own backlog and own 2 week sprints. So the granularity of the backlog items is < 2 weeks. Let's call such Sprints "Team Sprints".

With our stakeholders we do a 3 months planning. So we discuss which features shall be implemented, e.g., in Q4 2018. So basically, this is the planning for a 3 month Sprint. Let's call such Sprints "Master Sprints".

What we try to realize is something like this: There is a product backlog which contains high-level requirements with a granularity of max. 3 months. We create a Master Sprint for, e.g., Q4 2018. From the product backlog we drag&drop the features from the product backlog to the Sprint. Afterwards, each feature is broken down into tasks with a granularity of 2 weeks (so they fit into the Team Sprints). As a next step, the tasks are assigned to the teams. Based on this, the teams can organize there Sprints completely in own responsibility. Thus, the teams assign the tasks to their Sprints and brake them further down. On the master scrum board, we want to see the progress of the 3 months features, including the derived tasks. On the team boards we want to see the progress of the derived tasks and their subtasks.

My first idea was to use Epics for the Master Sprints, which can be broken down to Stories, which are assigned to the teams. The teams brake down the Stories to sub-tasks. However, in Jira Epics cannot be assigned to Sprints (which makes sense considering the Scrum theory). Next idea was to consider the Master Sprint more as a Software Release. However, it is not really comfortable to assign Epics to a Release. In addition, their isn't this nice Sprint board, which shows the progress of tasks and their sub-tasks in a structured way. I ran into similar issues when trying to find a solution using the Kanban board.

Current solution idea: Stories are used to define the high level requirements, which are then assigned to the Master Sprints. These stories are broken down to sub-tasks, which are assigned to the teams. The teams do the following for each sub-task: clone the sub-task, convert cloned sub-task to a Story, which then can be used for the Sprint planning of the Scrum team. These stories are again broken down to sub-tasks. The connection between the "master sub-task" and the cloned story is visible by the "clones" relationship. If a team completes such a cloned story it also has to set the master sub-task to complete, so that the progress is visible on the Master Scrum Board. Advantages: We can see the progress on two different levels (Master Sprint level and Team Sprint level) and we can do estimations on two different levels, which allows to determine the overall velocity as well as the team velocities, allowing a better planning on product and team level. Disadvantages: The manual steps (cloning/converting the sub-task and adapting the state of the sub-task to the latest state of the cloned item) are quite annoying and the "clones" relationship is not as nice as a real hierarchy (like Feature->Story->Sub-Task instead of Story->Sub-Task->Cloned Sub-Task converted to Story->Task).

Is there any better solution? I know there is this Structure plugin which would allow to define a better hierarchy. However, a) I'm not sure if it is possible to introduce this plugin in our company, and b) I don't know if the different hierarchy elements can used for Sprint planning and progress visualization in the way we need.

Sorry for the long text and thanks a lot

Chris

[Gundlupet Sreenidhi · Accepted solution]

@Chris, 

What you are trying to implement here is a Scaled Agile concept in JIRA. Where your master board acts as your Release train impacting multiple teams- each working on their own pace to achieve the train's objectives. This is exactly what Scaled Agile (SAFe) addresses.

We have a similar concept in my organization and we achieved this by using a new issue type which we created called demand. 

Let me break it down for you (taking your example):

We have created one Project (lets call this Master Project) to track activities on the Master train 

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. 

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. 

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

I'm sorry my answer is long ( but so was your question :P ). 

Hope I was able to give you some clarity. Let me know how else I will be able to help.

[Chris]

Wow, thanks a lot for all the detailed information. This helps a lot. May I ask some questions to your approach?

a) What is the advantage of having 4 projects? Somewhere I read that usually there is one project for each product. Is it about avoiding additional filter tags (e.g., via components) for assigning the stories to teams? Or are there any other advantages?

b) Let's say there is a "Demand XYZ". So it is possible to derive several stories from this for several teams? E.g., one team implements the business logic of Demand XYZ and derives 5 stories from it and another team implements the UI and derives 2 stories from it. And the status update of the demand considers the status of all stories which were derived from it? That sounds great :-)

c) Does one demand contain all feature requests, e.g., for Q1 2019? Or are there several single demands for this? If there are several single demands: How is your Kanban board configured for grouping the demands to the quarters and how do you assign a demand to a quarter (in my example this is done by drag&drop the item from the product backlog to the 'Master Sprint')?

Thanks a lot :-)

[Gundlupet Sreenidhi]

@Chris, 

a) 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..

b) Yes - 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. As mentioned in the previous thread - if any "derived" story goes to In progress, the demand automatically goes to in progress and only when all "derived" stories are complete (closed), the demand automatically moves to close.

c) No - 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.

I am sorry if I am confusing you. But this works really great!

Good Luck. :)

[Chris]

Again, thanks a lot! :-) Now everything is clear to me. Also big thanks for the hint regarding drag&drop functionality for versions in the Kanban Backlog. This is the functionality which I didn't found when experimenting with the Kanban board on Master project level.

I hope we can realize this in the same way, the solution looks really good to me :)

[Gundlupet Sreenidhi]

@Chris

Just a head's up. 

The Kanban backlog with versions is a new functionality released in one of the recent versons of JIRA ( i don't recall the exact version number it was released in). 

You can get the Release notes and change logs here: https://confluence.atlassian.com/jirasoftware/jira-software-release-notes-776821069.html

We did not have the functionality on our previous version (7.4) - we upgraded to 7.11 and now we have it. 

So somewhere between those version, the functionality was made available. 

If you are working on an older version of JIRA, I recommend you upgrade.

-Sree

[Troy Spetz]

I believe the JIRA version you are referring to was 7.5. See:

https://confluence.atlassian.com/jirasoftware/jira-software-7-5-x-release-notes-934719297.html

[Mark Didehvar]

@Gundlupet Sreenidhi Are you please able to share the setup for:

* ScriptRunner for JIRA

* Jira Workflow Toolkit

* Jira Suite Utilities.

I'm just getting started as a Jira admin and this implementation is exactly what I'm after :)

[John]

@Gundlupet Sreenidhi, @Troy Spetz  Would you please help me and answer the below scenario?

I am new to JIRA and Scrum and trying to learn with practical examples. I have a scenario as below.

There is a CRM tool. There are three different development teams(billing, API, Pricing) and one deployment team.

What is the best way to manage these 4 teams and run the scrum?

What is the best way to setup JIRA? it would be helpful if someone can explain with example for the above scenario.

how to plan for deployment? release plans, portfolio management?

How to track status of the teams and have a overall status update in a single chart or pictorial form?