How to use JIRA to capture a feature similar across the technologies (ex:Login to iOS, Android, web)

[Deleted user]

What is the better way to use JIRA to track the progress of similar story across technologies (Web, Android mobile & iOS mobile)?

I want the below use cases should be addressed

• The pace of development across technologies need not be uniform. That's said, the burndown chart should have an update if iOS team completes the functionality
• Cut down redundancy in capturing requirements and ensure the help of the tool if there an enhancement to any feature.

For example, let's consider the following user story which needs to be handled on iOS, Android & web:

"As a user, I want to login to the application via email & password, so that, I can access the required features"

Potential Solutions:

• Sol 1: Create three user stories one for each technology. Problem with this approach, redundancy content and the probability to miss the future update on any of the story which might lead to the messy situation. The benefit, burndown chart captures realistic update if the iOS team completes the task well ahead of Android & Web
• Sol 2: Create only one user story and create three separate tasks each per technology and relate them to the user story. And all tech sub-tasks goes under each task. Use hourly estimation to track burn down rather than Story points.

Please assess the above scenario and suggest an alternative

[Chris Saunders]

I'm not (yet) sure this is an answer!

This has been a hot topic in my mind for the past few months. In my team we have 2x iOS, 2x android and embedded developers working on things the apps have to control. We're a new Scrum team but there are some experienced agile/scrum/Jira practitioners among us.

We're tackling the problem you describe by using a single project containing a single instance of all user stories. Within a US any amount of sub-tasks are created for each platform and assigned to their component. At the moment we're only estimating at US level so we still have the task of working out how to capture velocity of the individual platform teams.

We've got separate, filtered boards to allow the platform teams to better understand their own sprint workflow but, basically, a Story isn't complete until all work on all platforms is done and tested.

The aim for us is to try and better coordinate delivery of each of the platforms to make sure focus and attention is given to a stories requirements by all that it affects. To try and reduce bits of the total effort being partially completed and 'thrown over the fence', then ignored until the receiver gets to it.

Also the embedded software has a life of its own (outside of it's interface to the mobile apps) to be managed. How one integrates that in to the project effectively is yet to be properly determined!

[ASweeten]

Hi Ravindra,

This is difficult question to provide absolute answers to.  I sympathize with how much simpler this whole situation would be if Burndown charts showed story points for sub-tasks or Sub-tasks had story points in general.  Right now, though, it is not even possible to add a Sub-task to a sprint directly.  There is a long and interesting discussion about story points, sub-tasks and burndown charts in this previous forum post.

Your situation is further complicated by the fact that you have multiple teams working on sub-tasks of the same story based on the platforms your application works with.  Sprints are designed for a single team to collaborate on a set number of issues over a specified amount of time.  In your instance, it might make more sense to setup multiple projects for each of the different platforms and run separate sprints accordingly. 

This will require a little more coordination between platform teams on sprint planning, but it will accurately measure burndown for the individual teams.  Also, you could clone issues and move them between projects easily enough.  The cloned issues will be linked together even though they are in separate projects.  I know this may not fit your original suggestions for how to architect the project, but it more closely resembles the way a lot of successful companies handle this situation.