6

Here is my situation:

  • I work with two SCRUM teams, iOS and Android

  • Each of the SCRUM team has its own Product and Sprint backlogs

  • We have shared Sprint Plannings, Reviews and Retrospectives (both teams attend) so that the products can stay aligned and that a given team can benefit from the knowledge of another team in tackling a specific problem as well as in story point estimation

Because the roadmap and features of both iOS and Android are pretty similar, both products are sharing the same backend engineers as resources. As a result, we create backend subtasks for given user stories in sprints and backend engineers attend Sprint Planning as part of the cross-functional team.

By backend work I mean server side work. We're talking about mobile apps here, so anything related to user management for instance. i.e. let's assume a user wants to delete his profile but he can't yet. A user profile deletion CTA would need to be available on the client, but it would need to work with HTTP requests to the server. So here, as part of the same user story ("as a user, I want to be able to delete my profile), we would have both client and server work together.

These backend engineers are mostly a resource for the mobile products, as we are a mobile-focused startup.

Should backend have its own backlog, separate of the mobile teams, or only be considered the owner of backend subtasks in each of the mobile teams' sprints?

Improve this question

3 Answers 3

Reset to default
3

I think that backend developers can be separated into third team.

Of course, somebody may say that teams will lose their cross-functionality. But if we will look to this situation from other point of view, than we will see that backend team are implement independent product.

In that case your both client teams will be stakeholders to product of backend team. Of course, backend team should have Product Owner, which will be separate backend requirements from clients User Stories and make Product Backlog (for backend service) based on them.

Interaction between teams will be within Review Meetings of backend team (client teams, as stakeholders, will be give feedback of backend problems, API usability and so on).

Disadvantage of this approach, that I described below, is that backend team should be in a step (i.e. Sprint) forward of client teams. This means, that Product Owners of client teams should plan two Spring ahead to allow Product Owner of backend team gather information about next Sprint. This make process a little bit less flexible.

Also, can be some problems with cost distribution for backend works between clients teams. But, if all three teams work for one customer (or in your case, for one project) it doesn't matter for you.

Improve this answer
5
  • so would you take a dev off each client team to be a product owner on the api team?
    – Ewan
    May 23, 2015 at 15:02
  • @Ewan Sorry, I deleted my previous comment. I made small mistake there. Not each. Development Team should have only one Product Owner. Anyone could be PO, but, by my opinion, better to assign developer from backend team to this role.
    – Sergey Kudryavtsev
    May 24, 2015 at 21:58
  • @Ewan He will communicate with client teams, separate backend requirements from future user stories of frontend teams and combine and prioritize them. Of course, this developer will lose his coding productivity, but whole team may increase capacity, because they will not attend in unnecessary interactions with frontend teams.
    – Sergey Kudryavtsev
    May 24, 2015 at 22:01
  • Hmm. seems wrong to me. I mean, PO can be a full time job. plus getting a dev to generate thier own user stories?
    – Ewan
    May 25, 2015 at 8:01
  • @Ewan I am afraid, I am not understand what are you worried about. Could you clarify your concerns?
    – Sergey Kudryavtsev
    Jun 5, 2015 at 15:00
2

As with most things agile the answer is "it depends". I'm going to tackle this at two levels, Product and Sprint Backlogs.

Sprint Backlog: Server Team has other work: If the server team has work unrelated to the needs of the two app teams, then absolutely it should have it's own sprint backlog. It has its own work to be done and the App work is just part of it.

Server Team only supports the Apps In this unlikely event, then my advice would be to move server team members into the App teams. At this point you are creating a "cake slice" where the team has everyone needed to release working, tested software.

Product Backlog: A product backlog is the total list of everything you want to build for your product. Typically a iOS or Android App is not your product, it is a method of delivery. For example, Evernote (just picking them as a popular product most of us know) has iOS, Android, PC, Mac and Web based apps. They all offer essentially the same functionality (within the limits of the software).

When you have one product and multiple delivery vehicles, then the recommendation is to have a single product backlog. You use the acceptance tests of the product backlog to drive what teams are engaged. For example, say Evernote wants to be able to print notes. They don't want to deal with cloud printing so the acceptance tests just list PC, Mac and Web. Creating a new note though, has acceptance tests for all their delivery methods. These also can be structured as "features" or "epics", higher level user stories which get decomposed to the team level.

Product Backlog items can then be decomposed into team specific user stories. So the iOS and Android team will both have a User Story for creating a new note which feeds up to the Product Backlog item of "create a new task".

And back to the server team, you also then drive server team user stories from the same backlog item. So printing to the cloud would require server work, so when Evernote started that, they'd add the acceptance tests to support that and these would be decomposed to the server team as user stories.

By keeping your product backlog aligned, you end up with less product drift (some computer apps are totally different between a Mac and a PC) and also tend to reduce load on the support teams since they will know they have to support more than one group. I'd feel sorry for the Evernote server team if they were asked to support iOS and then six months later Android and they built the cloud print to be hard coded to iOS, double the work.

Improve this answer
2

No, Although it is common to see.

In fact, I would argue that splitting your team across android/ios is probably also not a good idea.

Here's my reasoning.

You have one product, the App. User stories should be written from a user's perspective, not a technical one. ie you would have :

"As a User, I want Feature X, so that I can achieve goal Y"

not

"As a Programmer working on platform Z, I require the API to expose Feature X, so that I can implement feature X on platform Z"

The scrum team can break down the Feature X into tasks

  • add sprocs to the DB
  • update the DAL
  • update the service
  • expose the API
  • update ios app
  • update android app
  • update windows app
  • update website

etc

when all are complete then the user story is delivered

If you have Three teams, the API team will end up with two potentially conflicting feature requests from the ios and android team to implement an API they designed independently.

This leads to :

  • delay, as your app teams wait for api team resource to be allocated,
  • bad coding as your api team duplicate functionality for specific platforms
  • and general communication problems as multiple teams attempt to solve the same problem individually
Improve this answer
2
  • I'm curious how this works in the real world. Are there case studies? It sounds extremely unusual to see new development across multiple platforms initiate and complete within the same sprint. There's also the fact that new applications often launch on just one platform, and later port to others, and there's no reason to think that makes them not-agile (to the contrary, it gets them to feedback all that much faster). If a stakeholder doesn't like a feature implementation once seen, the fewer the platforms to rework, the better.
    – Wandering NPC
    May 22, 2015 at 23:22
  • hmm I wouldn't say its not agile, or that you would finish it all in one sprint. Just that separating teams by 'horizontal' layers has these negative effects. Sometimes in my experience they can be extreme. You have to question the logic of dividing the team up into these groups in the first place. often I think its done because of management preconceptions about 'types' of developer which are just wrong
    – Ewan
    May 23, 2015 at 14:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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