How do you best organize iOS and Android development of the same app in Jira?

[Christian Schmidt]

Dear Community.

I am working on a project, where we are developing an iOS and an Android version of an app.

I am curious how to best organize this in Jira, and I would love your input, and hear of your experiences.

So far, I have made a custom field, which is required, indicating whether the issue relates to iOS, Android or both.

But here is where the way to do it, can go in several directions.

Are you splitting the work on a User Story level?

A User Story concerning feature X is made in two identical versions - one for Android and one for iOS. They have their individual estimate.

Are you splitting on a subtask-level?

A user story concerning feature X is made, and on a task level, you differ between iOS tasks, Android tasks and common tasks. The story has a common Story point estimate for the whole team, which contains both Android and iOS developers.

I can see pros and cons to both strategies.

Much of this debate is related to how you are running your agile teams (have you split them into Android and iOS teams), and not Jira directly, but since how I am going to organize it will be reflected in Jira, I am right now seeking inspiration.

I hope you can enlighten me :)

Best regards

Christian

[Carlos Khatchikian]

Hey Christian,

my name is Carlos, I am the Team Lead of Jira Mobile here at Atlassian and I wanted to share how we do things here...

Before we had 1 project for iOS, Android and Backend. We had components for each and we had 2 different boards separated by this components. In the end it didn't work well because you have different release cycles and different release versions, different story points estimations, different labels, etc etc...

In the end we finished with 2 projects. One for iOS and one for Android. Backend is done in any of those projects basically because the mobile devs know how to do backend. Releases, versions, and workflows are clear for what each team is releasing right now. And yes we have to duplicate Epics and User Stories. But I found myself that each team works differently and this gave enough room for every team to behave as they wanted. 

Now this setup works because we have one separated team that does iOS and one separated team that does Android. If by any chance you are working more on a Squad model you might want to have 1 project and have maybe a custom field per squad. 

Hope this helps!

[Rich Byard]

But when we have multiple projects it will be 2 separate projects (android & iOS) for each project?. Do you have a better way of handling this multiple project scenario?

FYI - we have separate devs for iOS and android

Thanks 

[Ahmad]

Hey Christian,

We have the same case that you have triggered to differentiate between iOS & Android in JIRA using SCRUM board,

Did you find any feasible solution to overcome duplication of projects, stories & tasks for each team (iOS, Android)? 

Is there any new features expected in JIRA to overcome this hurdle 

[Chris Saunders]

Hi all, 

it seems there are many of us on this same journey!

Interesting to hear that Atlassian team themselves are battling this same issue ;)

We have an iOS, Android (with shared QA) and backend team.

We have common stories as well as platform specific bugs/tasks

I think I've been through most of the setups that have been described above and have realised benefits and drawbacks in each approach! 

The biggest issue I've found with discrete projects (which work best for the teams), aside from the risk of inconsistency in stories, is that looking much past the next sprint managing the backlog priorities is a nightmare! Especially when interdependencies are thrown in to the mix!

I'd be glad to hear of any further insights.. We've started using portfolio which looks like it might fuel more revisions to our process but I fear it's actually just going to kick me off in another circular hunt for utopia... 

[Rayen Magpantay]

Hi Chris,

I'm a Product Manager in the Jira Mobile team. Do you want to chat sometime? I'm keen to understand mobile development workflows and see how we can support you better here. We can share what we do internally, maybe you can learn from us and we can learn from you. Please shoot me an email at rmagpantay@atlassian.com if you're interested. 

Thanks!

[Thor]

@Rayen Magpantay  I really would like to see your comment of this.

1. We have a single development team working on all three (iOS/Android/web portal) at the same time. Does this level of complexity make a difference in terms of how we manage the three projects, as opposed to if we had multiple teams?
   
   
2. In terms of using Scrum and planning in sprints: To manage all three projects, do we have to start three separate sprints every two weeks? Can we not define a single „master sprint“ that covers work on all three projects. As we have a single team, do you have any recommendations regarding how to plan sprints, future releases and measure velocity – without overview and planning becoming too complicated?

[Hassa Islam]

Hi,

I have been working as Product owner in multiple team, What I did previously, 

 - I created 1 project and where I add custom field which describe iOS, Android, Backend API, Designer and QA Task within same Epic.

- But in above mention point, I duplicate each user story and task separate for Android and iOS.
- After that in one Sprint each team member select user stories according to the business value and proceed accordingly. 

- Scrum Team filter their task on Board and proceed on their deliverable

I also did separate Project for both Android and ioS but in that case i feel that QA, Designer and Backend API developer would not sync with any one of the Project if we place it in one project.

That's why i choose to work with above approach.

If you have any better suggestion, Please advice

Regards,

Hassan I

[zoha131]

   We are a small team. Android, IOS, WEB & API each team consists of a single member.

This is how I am planning our project:

1. Four different components for each team with default assignee.

2. Epics for features. In each epic, we will multiple issues.

3. In each issue, we will have subtask for each component. Here we will duplicate issues for each team.

4. We will use the same MAIN versions across all team. For hotfix versions, we will use a tag for that as Jira doesn't allow versions for the component.

Eager to know what others think about this approach?

[Rayen Magpantay]

Hi Zoha,

I'm a Product Manager in the Jira Mobile team. Do you want to chat sometime? I'm keen to understand mobile development workflows and see how we can support you better here.

We can share what we do internally, maybe you can learn from us and we can learn from you. Please shoot me an email at rmagpantay@atlassian.com if you're interested. 

Thanks!

[Sneha Sasikumar]

I am facing a similar challenge, am working on JIRA PoC for my customer and account. We have picked couple of projects and one of them is a mobile app team. 

The challenge that i have are as below

1. A particular feature needs to be rolled out in both iOS and Android - both the dev team is different

2. There is an API team which is common to both iOS and Android team.

3. There is another team which is not part of the app project but we are linked to them heavily consider it more like an upstream application from where data is retrieved to and fro consumed by the mobile app/api team

4. I have a common QA team to test the mobile app

The upstream website team is created as a project. The mobile app is created as a project.

Now if i have a feature - am creating this as an epic and breaking it down into user stories.  What i have done is create components as iOS, Android, API, WCS (incase of website) and then creating sub tasks under that user story. 

This is because both the apps will go into public store (production) on the same date even though they are being developed by separate sub teams. This is helpful cause unless both apps are build for the user story that particular user story will not go into public stores.

So say, i want to enable Registration as a feature on my app then my Epic is Registration, then i create user stories say US A, US B, US C. all three are applicable for both ios and android so it will have subtask say, US A_ST_iOS, US A_ST_Android, US A_ST_Api, US A_ST_WCS. 

Let me know if this helped! 

[Vitalii]

Hi @Sneha Sasikumar,

Thanks for sharing your approach.

May I ask a question regarding estimation.

1. Do your teams estimate in Story Points or in Hours?

2. On what level your teams put their estimations - stories or sub-tasks?

2.1. In case of story level - how do you manage different estimation for Android and iOS? Do you sum it? 

2.1.1 How do you check capacity before planning?

2.2. In case of sub-task level - How do you check capacity before planning? Do you check only remaining time (as it is the only way how to sum sub story estimation)?

In general thanks @Christian Schmidt for rising this question. I have the similar situation that I'm looking forward to hearing any ideas how to organize it.

I can share my thoughts:

- currently we have 2 projects for iOS and Android. We do a separate capacity calculations, in most cases separate refinement due to different velocity of teams (it means that one team can already implement some features that other haven't started). And this approach works more or less fine but I don't like that we should clone (duplicate) our features and epics for teams. It because there is a lot overhead in supporting this features and tasks (you should change on the first project and then you should not forget to do the same for another one). To avoid text duplication and to have it the same for both teams I even think to have story description in confluence. But to be honest I doesn't like this idea!))

- Also I think about the following approach: to have all features as epics with one description and then just to create a stories for both team with titles and empty description. What I don't like in this approach that is my jira I cannot move epics into a backlog level and it will make a mess in a future with this tonnes of epics on the left panel;

- One more idea is to create a common Kanban board that contains descriptions for stories and Android and iOS projects will have links to this board. But supporting this might make even more mess. 

It's interesting to hear your thoughts about it. 

BR,

Vitalii 

[Omnia Mohamed]

HI Vitalii,

I have the same problem but worst i have four platform Android TV , Apple Tv, iOS Mobile, Android Mobile, and each platform has a different release plan according to team capacity and users segmentation.

So to track the delivery we have four jira projects , for each platform a jira project , it's perfect to track the progress however it's so messy to duplicate the user stories  across the four projects considering that all user stories has common acceptance criteria with percentage 70% 

So Does any one suggest a good solution ?

I suggest to has one common user story that contains the common functionality/ acceptance criteria on confluence and link it in jira User story however i don't recommend that 

[Rayen Magpantay]

Hi all,

I'm a Product Manager in the Jira Mobile team. Do you want to chat sometime? I'm keen to understand mobile development workflows and see how we can support you better here.

We can share what we do internally, maybe you can learn from us and we can learn from you. Please shoot me an email at rmagpantay@atlassian.com if you're interested. 

Thanks!

[Patera]

Hi Omnia, i'm facing the same problem. Your suggestion is interesting and i'm also thinking to try this way: 

I suggest to has one common user story that contains the common functionality/ acceptance criteria on confluence and link it in jira User story however i don't recommend that

But why don't you recommend this? Is it because you can't read the description in the link? 

[Shaakunthala]

Hi Christian,

Interesting question, and I'd love to continue this discussion.

I have a question - is there any particular reason to use a custom field instead Components in JIRA? Components can be used to specify a given issue as iOS/ Android/ Both.

Splitting a user story into two stories is a good strategy in cases where development work associated with iOS and Android significantly differ. This is not to be a strict rule, but depending on the story team can decide it during iteration planning.

In other cases where development work associated with both platforms are much similar, you can use both components for the same story (multiple components for a single issue). In this case, just create Android/ iOS/ common subtasks.

Bottom line: Best strategy is a case-by-case strategy and it's up to the team to decide during iteration planning/ backlog grooming.

Please let me know how it goes.

Thanks!

Shaakunthala

[Thomas Bjerring]

If the choice is to use subtasks split into iOS and Android versions, is there a way of not showing the overall story on the board, which in our case is assigned to the team PM?