How to organize multi-platform development issues in Jira and estimate their effort?

[Lorena Guerini]

Dear community,

I'm facing some issues organizing sprint estimation in Jira and I'd like to hear from you what your suggestions are.

Our team consists of multiple-platforms developers (iOS, Web, Android), backend developers and QA. We have 1 project in Jira and we only create 1 epic/1 User Story for each new feature to be developed. But, when it comes to providing the story points, we need to consider that iOS and Android have different effort, for example, and also that same Story may be related to a backend work as well. What is the best way to proceed in this case?

Today we've broken this User Story into Subtasks for each platform, and summed up the estimates in the US. But this is not working smoothly, because sometimes we may have a lot of points in the same US, and some of the work might not be accomplished at the same time (eg: android and backend will be done at sprint 1, iOS and web in sprint 2). We also don't like the idea of duplicating the User Story because it could cause more confusion and would not "respect" the issue concept. Also creating different projects for each platform is not a feasible option since the devs work together.

I'd like to please hear from a Atlassian expert how should we handle this. I saw that a similar question was made a few years ago, but the answer does not fit my case. I earnestly ask for the e-mail contact of someone who can help me. 

Thank you

[Mark Segall]

Hi @Lorena Guerini and welcome to the community!

Although your teams work together, the fact that they don't "swarm" on the same story means that the best path forward is to have separate stories for each of the work efforts.  A story should be a small enough effort that it can be started and completed within the same sprint.

Based upon my interpretation, I would recommend more scrutiny on story decomposition. Your stories probably could be elevated to epics and subtasks into stories.  As for structure, if members of the team are working at a different pace from each other, it's just forcing a single scrum mindset when in reality, they are separate teams that just need to stay in close collaboration on final product and timelines.  If this is your situation, you probably should break them up into separate scrum teams and look into expanding into a  scrum of scrums model.  As far as Jira goes, you could go separate projects with a shared board for holistic visibility and make use of advanced roadmaps for shared planning and releases.

[Lorena Guerini]

Hey, Mark. Thanks for the quick response.

About separating the stories for each kind of work, we wouldn't like to go though this way because the Product Owner is the one who writes the story, and therefore it's not up to him to say if it's going to be needed some backend effort or not for implementing this US, for example. So he/she couldn't anticipate in creating different US for each item since it's up to the development team to see how the work is going to be implemented.

About separating the devs into different Scrum team, it wouldn't work because we have a small team with 1 or 2 developers for each platform/stack. So it wouldn't make sense having different ceremonies for each of them cause the forum might be very small. 

[Mark Segall]

because the Product Owner is the one who writes the story, and therefore it's not up to him to say if it's going to be needed some backend effort or not for implementing this US

I would recommend revisiting your sprint planning.  I've seen this as a common issue where scrum teams think that only one person should be responsible for stories.  This is untrue.  The product owner should be writing stories from a business perspective and the dev team should be performing that decomposition during sprint planning to break those stories into technical stories that fit into how they need to work.  So, the Product Owner is doing their job by creating the stories, but the dev team needs to place more emphasis on that story decomposition.  They should be empowered to say "This is too big to be a story... Let's elevate it to an epic".  

About separating the devs into different Scrum team, it wouldn't work because we have a small team with 1 or 2 developers for each platform/stack. 

Understood, but I still go back to story decomposition.  If you want everyone on the same scrum team, that's totally acceptable. Contrary to what many think, Agile isn't a one-size prescriptive solution because different real world variables (usually resource constraints) will create challenges with following to the letter of what we are all taught.  However, I would heavily scrutinize any story that requires spanning multiple sprints.  That is the red flag to me that says the team needs to place more emphasis on story decomposition.

[Lorena Guerini]

Thank you, Mark. I get what you're saying. I'm going to try to implement this in the following grooming sessions and see how it works. Thanks

[Marek Cais]

Hi Lorena. I'm in a similar situation like you were. I'm curious how you solved it in the end. Would you be willing to share an update? Thanks!