0

If yes, I want to make sure consistency is maintained in both the applications. Also, let me know if I can use labels or components. I also have a team which create web services for these projects which are common for both.

1

Both may be viable options. My rule of thumb is that each deliverable product should be its own project in Jira, which enables more effective use of the built-in functionality around components, releases, and versioning.

If you are building the applications independently, using native programming languages, then two projects is definitely the way to go. If you've got two separate code bases that leverage native technologies, you may end up able to support different functionality in each application. You may also have more freedom to follow device-specific user interface guidelines, which would require different UI mockups to be attached to guide developers. And since you have separate code bases, you may have bugs in one product or another, and these bugs may drive patch releases (new versions) of the app for one device, but not the other.

If you are using a framework that enables you to target multiple platforms with one codebase, then perhaps it's OK to consider one project. If you decide, in the future, to spin off and go native, then you can follow the suggestions above and have one Jira project for each deliverable entity. You may continue to maintain your existing framework-based app for a while, while managing two additional native projects, until their hit a state where they can take over.

In both cases, I would use a separate project for your web services. If you have a requirement or bug that depends on changes to the web service, Jira allows you to link the issues and identify that one issue depends on another. Various plugins can also add functionality to these links, to let teams know when a dependency has been resolved, for example.

  • I hope it is ok to have some friendly disagreement here: I don't see any reason that I would need to have separate projects to get all of the benefits you mention. I could have a backlog item for saving user profile and the team would implement web services, iOS, and Android all in that backlog item. I don't think it is the only right way, but it is perfectly viable and it does support feature consistency. – Daniel Jun 12 at 14:10
  • @Daniel You could do it that way, yes, which is why I said that it's viable. However, it makes it harder to visualize and track work, and harder to visualize dependencies (the mobile teams can mock out solutions, but can't release until after the web services team is done and does integration tests, for example). It's not my recommended approach - I would strongly recommend separate projects. – Thomas Owens Jun 12 at 16:08
  • Ah, I see. I had a different starting assumption - that a team would have iOS, Android, and Web services all in one team. Re-reading the question, it seems that there are separate teams. – Daniel Jun 12 at 16:13
  • 1
    @Daniel Yes. Even if they were one "team", I do think that there's a higher level project management aspect with respect to visibility, scheduling, and dependencies that warrants treating each one as a separate effort over three distinct products with their own releases (and perhaps release cadences), versioning, defect tracking, and requirements. Of course...there are at least two ways to slice it, maybe more. – Thomas Owens Jun 12 at 16:31
0

If you are looking for a consistent feature set across both, it feels like you would get more value out of treating them as the same backlog. I would consider actually going a set further and making " works on Android and iOS" part of the definition of done so that a story like As a user, I would like to see a record of past actions" would only be done when it worked on both.

  • ...if I am an iOS user, what value do I get out of something working on Android? Why would that be in the Definition of Done for an iOS story? – Venture2099 Jun 12 at 9:10
  • @Venture2099: Why would you write a story to implement a feature only for a subset of the possible users (i.e. only those that use iOS) instead of all users? – Bart van Ingen Schenau Jun 12 at 12:52
  • The original question said they specifically wanted to provide a consistent experience. Plenty of groups do separate the efforts with a lot of success, but you invariably have some drift on available features when you do that. – Daniel Jun 12 at 14:06
  • Why? Lot's of reasons. It tightens the feedback loop, it releases business value, it lets me prioritize my most important users, they have separate functional and non-functional criteria...the question is not why separate them, the question is, what compelling reason do you have for making two separate platforms a Definition of Done. For instance, the iOS platform is making it mandatory that all 3rd Party login systems in use also use Apple login as well. How do you make an Android adhere to your definition of done now? or is it just a "Definition of kind of done?" – Venture2099 Jun 12 at 16:14
  • Something being a priority does not make it a Definition of Done. Both Android and iOS can be priorities, but making them both a Definition of Done is, being honest, antithetical to Agile. – Venture2099 Jun 12 at 16:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.