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

Question

I have a team of 8 developers who are working across different technologies (backend, iOS, android and web). We are using Scrum.

At the beginning I was using a board for each technology but it was so messy because of duplicate user stories across the various projects.

So I created a classic Scrum board to manage all the stories, bugs, tasks and subtasks. Even if I tried and read everything I'm still not sure my solution is the right one.

With this new solution now I have a story for each feature so the team can discuss an implementation in a single place. During the Sprint Planning we explode this story into different sub-tasks assigning each of them to a component (backend, iOS, android and web).

My problem is that I can't give story points to a story because it's not related to a single technology. I can't neither give story points to a sub-task. Should I then have a story for each technology? Every solution has his pro and cons and I don't know what is the best one.

So does any one suggest a good solution? I am curious how to best organize this in Jira, and I would love your input, and hear of your experiences.

Answer 1

Either way, you're going to run into problems.

Based on my experiences with Jira, each product should be a separate Jira project. That means your iOS application, your Android application, and your web application are all separate Jira projects. I'm not sure what you mean by "backend", but if you are maintaining APIs that are shared among all of these products, then that would also be its own Jira project. This structure allows you to take advantage of Jira's functionality around versions, Releases, and Components, among other features.

You can create boards that pull in issues from all of these Jira projects, if necessary. The boards will give you access to viewing the state of work or easy access to Sprint-based metrics.

This approach will also enable each issue to represent what really needs to happen. Your backend databases and APIs, for example, would likely block new functionality from being released into one of the applications. If you attach mockups and design details to each Jira issue, this isolation also helps to make sure that the iOS work is distinct from the Android work.

Cloning the initial issue into the other project may be a good starting point to help manage work. There are also new features in Jira around issue automation that can automatically create issues in various projects based on triggers (which include creating an issue that meets various criteria). There are tools that can simplify the creation of a stub issue.

Answer 2

My problem is that I can't give story points to a story because it's not related to a single technology.

Why? The team can give an estimate for the whole feature, they don't need to break it down by technology. If the amount of effort varies across the technologies then the team should use a compromise value for the estimate.

This is similar to the question of how testers and developers estimate on the same story.

For example, when you are adding a new search feature you might have a conversation like this:

"From the web point of view this is pretty quick, something like a 2"

"On iOS it is tricky because there is no search API available, it's more like a 5"

"Android is similar to iOS on this one"

"Not much work to do on the backend, maybe a 1?"

"OK, so overall, shall we go for a 3?"

As your team contains specialists, it may also be wise to do a sanity-check. For example, after you have added the stories you want to the sprint and created sub-tasks, you could quickly check that no discipline is either overloaded or under-loaded.