Mobile app - separate product?

Now.. do I have 1 product here and should use one Product Backlog for that, or perhaps these are 2 separate products and should have 2 separate backlogs?

@Bartosz Krawczyk, This is a very interesting question, and thanks for asking. Honestly, it made me think a bit. My opinion is that it is still a single Product and hence would require a single Product Backlog.

My reasoning is based on the below excerpts from the Scrum Guide particularly the areas I've marked in bold.

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.

The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.

Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.

Based on the above, my thoughts are that the mobile app is an extension of the same product. It can be considered a feature/enhancement that will help it become competitive and useful. Hence, it will be part of the same single Product Backlog.

Hope this helps.

PS: I'm also curious to see the perspective of others.

Identifying product boundaries can be challenging. I don't think there's one right answer, but here are some things you might want to consider (for now I'll refer to the potential products as 'components'):

• Are the value and cost of these components being accounted for separately?
• Can both components still represent value if the other is removed from the market?
• How might these components diverge in the future, and how important would it be to avoid divergence?
• Are there any shared dependencies (e.g. codebase) where changing one component will require a change in the other?
• Would it make sense for the definition of "Done" to differ for these components?
• How much overlap is there between the stakeholders of these two components?
• Do you have separate Scrum Teams working on each component?

Now.. do I have 1 product here and should use one Product Backlog for that, or perhaps these are 2 separate products and should have 2 separate backlogs?

Should they be inspected and adapted separately, so the value of each can be independently optimized?

Another possible consideration is that you have 3 products. If you have a web application and a mobile application, you probably have APIs, server-side logic, and infrastructure (a back-end, if you will) that is exposed to users through either the web or mobile front-end. If the back-end doesn't support a given (functional or non-functional) user need, then it could block work in either front-end.

I think that the questions posed by Simon Mayer are good for determining if you have 1, 2, or 3 products. I'm not sure that I would consider separate Scrum Teams working on each product, though. Although it's best if each product is supported by a Scrum Team, that isn't always feasible, especially in very small organizations. From a product management perspective, though, considering the work as separate products early would let you scale the organization as you can support multiple teams.

I like to use examples, how do you think i.e. facebook manage their service with messenger? Do you think that it is rather managed as one product with a huge backlog, or is it rather separated as different products that are exclusively tightly connected to create synergy? I do not know this, but I imagine that the second approach seems logical, that despite some connections, each of these things (facebook site and messenger) can be considered as a separate product.

As Simon Mayer said, it can be challenging to define such boundaries. IMHO even if there are some shared parts in the codebase, often taking the situation in hand as one monolithic product lead to unnecessary complication and overwhelming process, that could be avoided by treating the same situation like a bunch of products (aka companies) that wants to cooperate and create synergy. Another example may be the automotive industry, where different brands share know-how and parts, despite offering different products (cars) that also compete with each other (i.e VW Group)..

@Simon Mayer, you ask 

• Do you have separate Scrum Teams working on each component?

Independent of the answer, you can also have several Scrum Teams working with the same PO and same PBL. I think the question if they are dependend is a good one, because if both use the same backend or the web-app has some transfer classes, the mobile-app is depending on what the web-app is providing and then it should be managed centrally.

And @Ian Mitchell asked

Should they be inspected and adapted separately, so the value of each can be independently optimized?

That can also be done with the same PO and PBL in seperate teams, couldn't it? The PO can adapt the web-interface to allow user administration, which will not be done in the mobile-App. Or he prioritizes some functionality in web while in mobile a different thing is implemented, as the usage of both apps are different. 

That can also be done with the same PO and PBL in seperate teams, couldn't it? The PO can adapt the web-interface to allow user administration, which will not be done in the mobile-App. Or he prioritizes some functionality in web while in mobile a different thing is implemented, as the usage of both apps are different. 

I'm finding that arrangement hard to visualize, so I'd suggest that transparency might not be optimal.

Hello everyone,

I am also faced with the same dilemma, whether to organise web and ios + android apps as separate projects. As many mentioned, there is dependency on the API which is connected to web. 

I am also thinking about a scenario where we use Jira to track the PBL which is in turn linked to BitBucket deployments. I would want to see the product backlogs and deployment messages working in sync between these platforms and the messages generated shows appropriate visibility. 

Not sure whether Jira support labels to segregate web and mobile backlogs or do we need to manage the same via titles codes. 

Any suggestions? 

In my opinion, this question doesn't have a straight answer and depends upon a number of factors, as @Simon Mayer rightly put.

I agree with @Steve Matthew that it essentially looks like the extension of the same product and can be managed via a single Product Backlog. However, the flip side is - we do not want our Product Backlog to be huge & un-manageable, having items related to developing the web application (with all browser-compatibility), iOS-version, android-version and what not.

However, its a fact (& cannot be ignored in our final decision) that its gong to be the same back-end, APIs and most of the same front-end components that are going to be re-used across all the platforms of the application.

So, considering that, we need to work collaboratively with the entire team and brainstorm and come up with a way forward to this. Teams need to keep in mind that the individual Scrum Teams should have a minimal level of independence in working through Sprints and should not be spending time waiting on other teams to come up with dependent components. In that case, if they decide to come up with separate Scrum teams for each platform, they can make use of a scaled framework like Nexus to have a close ecosystem of all the teams working in unison and continuously addressing the interdependencies and mitigating any risks, should they arise.  

I think there are many considerations to take into account:

• Is the complication/length of the backlog a criterion to split/create a new product? (personally, I don’t think so).
• Could you make a cross-functional team to build independently the mobile app: for example: add backend/ API developer(s), designer(s), etc…
• If the app would be developed with native technology, will you consider one product for the android app and one other product for the iOS app?
• Do you think that the same stakeholders will be engaged for both the web & mobile apps?

++++++++++++++++++++++++

There are mainly 3 possibilities:

1. OPTION1: keep 1 product, 1PBL & 1PO: mainly for the small organizations.

Issue: The team size could easily exceed 9 members

There will be more than 1 increment produced each sprint and demonstrated during the sprint review.

      2. OPTION2: Apply the Nexus framework: create a new team associated with the same product.

Issue:

The Nexus guide says: “The Integrated Increment represents the current sum of all integrated work completed by a Nexus.”

We will have 2 (or more) increments with the mobile app(s) and not a single integrated increment.

Could we consider the Nexus increment as the sum of the increments?

      3. OPTION3: Consider it as a new product with a new PBL.

My preferred option: I would say having 2 products, so 2 PBL managed by the same PO is the best option for me, as the Product Owner is mainly a role and not a Person.

This will avoid:

• having 2 persons making the same market research, tracking, etc...
• having one big PBL difficult to manage
• having long sprint planning and refinement meetings with people involved in only half the topics (either the web app or the mobile app).
• demonstrating 2 (or more) increments during the sprint review

The team(s) working in the mobile app(s) should have a backend developer(s) to be cross-functional and independent.