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

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

3 answers

1 vote

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!

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

 

 

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?

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! 

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 

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 

Suggest an answer

Log in or Sign up to answer
Community showcase
Published yesterday in Jira

How you can achieve compact and easy-to-maintain workflows in your JIRA( Server)

This approach requires you to have the JIRA administrative rights. The main aim of this article is to help you achieve an organized, easy-to-maintain workflows in your JIRA instance thereby, reducin...

195 views 0 0
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you