Managing platform products on Jira

[Dana Amer]

Hi there,

We have multiple products (web, iOS and Android) that are developed separately by different team members. All products share data with each other, so releasing a feature in one product may affect other products.

The team has been using multiple projects with separate releases, and they tried using one "global" project with multiple releases, but I still feel things are a bit hard to manage properly.

I was wondering what is the best practice of managing this on Jira?

[Ste Wright · Accepted solution]

Hi @Dana Amer 

It depends - for example:

• What do you find difficult about the current setups you have tried?
• Are releases to each platform independent of the other two? Or can stories from all platforms be in the same release?
• Do you release via Epics or Stories? Or both?
• Is the team just one team (eg. 5-10 users) or does team refer to multiple development teams?
• Is it multiple backlogs with different Product Owners? Or one central backlog?

If it's just one team of users...

• I would stick to one project - this allows your team to work on issues for all your different applications and have flexibility around releases - either joint or separate.
• I would categorise the work using components. As this is multi-select, you could have an Epic which has multiple components as a feature might be developed on more than one application.
• I would consider whether a more advanced split in data points is needed - for example, if a story needs to identify which application is being worked on and which it would impact - you could use a custom field for "Worked on Application" vs components for the rest, or use identifiers in the components - eg. "W: Application" is worked on, "I: Application" is impacts.

If this is multiple teams...

• I'd consider having one team/application per project
• This would allow for the work to be divided into three clear groups - and the team would also have its own individual versions, components, permissions, workflows, etc so that they can be flexible in their ways of working
• If you want to have a central project for major releases - you could decide that application-specific projects contain the stories, whilst the central project has Epics - i.e the features being developed. Epics and stories do not have to be in the same project to be linked to each other.
• To show relationships between different issues which might impact each other, use linked issues to show "blocks / is blocked by" or "relates to", etc

In either case, I'd then use Dashboards to show what is being worked on per application, show progress, etc.

Let us know some more specifics about your team setup and if any of the above sounds of interest :)

Ste

[Dana Amer]

Thank you for the time you took to answer this Stephen, much appreciated!

Answering your questions in bold below:

• What do you find difficult about the current setups you have tried? Two things, managing the backlog(s) and managing the scrum rituals
• Are releases to each platform independent of the other two? Or can stories from all platforms be in the same release? It depends, we may release for Android separately without needing anything from the other teams or a single story can require the web and iOS teams to both work on it to be released, so you can consider all platforms are interrelated
• Do you release via Epics or Stories? Or both? Stories mainly
• Is the team just one team (eg. 5-10 users) or does team refer to multiple development teams? Well, we have a bit of a tricky situation, our whole dev team is 10 people, but we have 2-3 developers for every platform (web, android, iOS) since each team have a different skills set and can't work on the other technology
• Is it multiple backlogs with different Product Owners? Or one central backlog? We tried both but with a single product owner for the two cases

To give you a better idea about the products structure, we have a web app that is used by the admin user to manage the setup on the mobile apps (android & iOS). While using the mobile apps, they send data back to the web app which shows a dashboard for the admin. That's why the products are closely related and their releases affect each other.

Since our teams themselves are very fragmented I guess it would make more sense to use the "one team" approach you suggested. I really liked the idea of having custom fields with the application impacted, I guess mixing that with the components would make it easier to organize work right?

[Ste Wright]

Hi @Dana Amer 

So from above, I can see:

• There's some complexity with managing the backlog and rituals for a sprint with the current setup
• Releases can be interrelated
• Stories are the main source of work and release
• The development team is one team - but in groups of users
• There is one PO - and to an extent, one product (with three platforms)

So this is what I would suggest at this point:

1. One Project: It sounds like you have one product with three integrated platforms. I would start with one project (which represents the product itself) and tracks all work across Web, iOS and Android
2. Releases: As you have one project, releases can be joint or singular - there is flexibility there. You could use a naming convention to show which is which.
3. Stories: You want stories to have a clear path from creation to completion - I would consider keeping stories to a single platform, rather than passing it from Web, to Android, etc. You could relate stories which rely on each other together - for example, using linked issues (blocks / is blocked by, relates to, etc). If you do need to have a story worked on by multiple team members, I would at least consider splitting it into sub-tasks based on Web, Android and iOS singularly.
4. Epics: It's hard to say if this is the right approach - but I would consider Epics as grouped functionality. This could be single or multi-platform based, but this will create more of a building block for your team to both work off - and show progress to the PO and Stakeholders as a whole.
5. One Scrum Board: If it's one backlog, I would stick to one board. It allows your PO to organise the work into actual priority. Also, if you intend for your team to work as a unit, you want them looking at all the data in order of importance, not just their own parts. You can always slice up work based on platform, using quick filters or swimlanes!
6. Parallel Sprints: A single sprint should suffice. But if you did want to have multiple sprints - you could do that from one board. In Jira Settings > Products > Jira Software Configuration, you can activate Parallel Sprints - which allows for multiple active sprints on the same board. That way the PO could still order the backlog as they see fit, but each sub-team could work on a separate group of work in the same timeframe. This does mean separate reporting though per sprint run - so it depends if full team reporting is important to you.
7. Issue Identification: I would definitely utilise components as a multi-select field - such as for "Platform Impacted". As I'm suggesting each Story should be for a single platform, you could also have a separate field for "Worked On" platform - such as a Select List (Single Choice) with iOS, Android and Web. This would make it easy to create swimlanes, quick filters, etc on boards - and have work split down into platform on Dashboard Gadgets.

Lots to digest here! Let me know if there's anything you're not sure about - or have any questions!

Ste

[Dana Amer]

Thanks Stephen! That makes perfect sense for our case, I'll try this out with the team starting next sprint :) 

[Ste Wright]

Awesome :) - let us know how it goes!

Ste