1

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.

But what is the best practice here for integration of the necessary backend work?

Do you include this backend work in your user story estimates for one of the teams (i.e. iOS team), knowing that once the backend work will then also be done for the other client team which might be lagging behind?

How do you include backend work in your velocity estimates?

And 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
4
  • As I understand, both clients have the same backend part, I'm right?
    – Sergey Kudryavtsev
    May 12, 2015 at 17:43
  • Hi, pretty good questions. You could help others find good answers by seperating the different questions in different posts, e.g. Integration of backend work, backend work and velocity, where to track backend work. In addition, what do you understand as backend work? Could you provide an example.
    – Tob
    May 12, 2015 at 18:02
  • @Depressive_Bore exactly, both clients have exactly the same backend.
    – user17129
    May 12, 2015 at 18:21
  • @Tobias Thanks for the advice. To answer your question, 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. The user profile deletion 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.
    – user17129
    May 12, 2015 at 18:25

3 Answers 3

Reset to default
1

Since it's the same product and you iterate same feature set in a given time-box; why use different scrum boards?

It's not about maintaining your codebase, it's about managing your product with your team.

Let's say you're about to implement a new feature: "User Profile Update"

All parties (iOS, Android, Backend) will work together on this functionality. You should groom together to refine feature details to make sure everything is all right.

You can create an "Epic" for a major feature and create stories within this Epic. Thus it will be easy to track major features and (sub-)stories.

You'll need to create different stories for different type of development.

For a given to-be-developed-feature, it may be too easy to create mobile application part and too complex to build backend logic. This means different complexity points to track down.

Also this is important for creating similar experiences on both platforms your products work on.

At the end of the sprint, it's the one feature you're deploying and it's the one feature you're marketing about: "Yay! We have user update feature now!"

Please do not forget, Agile Development is all about iterating features not codes. If you're unable to release your development, it never existed at all.

——

Besides, if the total number of these people more than 9 people, you should consider implementing "scrum-of-scrums"/distributed-scrum practices.

Improve this answer
0

It's hard to say without being there seeing your teams operate, but it sounds like you have a small team of engineers who are completely focused on back-end services. In other words, it sounds like you effectively have three teams that all share the same meetings, not two.

While there may be some advantages is letting the teams have their own meetings, I'd say if it's working for you, great for now. As far as if you have a separate backlog, I'd ask if that is really what is happening now and do you gain any value by adding the stories into another backlog or are you just trying to force the stories in to fit an expected format?

Again, I want to point out that this is a starting point and like any agile teams, you should always be looking to improve both your teams and your structure. It sounds like you've got some strongly silo'd skills and having a more T-based skillset where people have their specialties but are comfortable in each others skills too could help you out. If that backend team gets too swamped and someone who is an Android or iOS engineer can step in and carry some work if needed, that's a very valuable option to have.

Improve this answer
3
  • Thanks for the response. I'm not sure I understand your first question. Today, we have separate backlogs between iOS and Android but not for backend, whose work is integrated within iOS and Android ticket subtasks. Today, we have two backend engineers whose role is to support the mobile engineers so I'm not sure about calling them a full-fledged team yet, but they're bound to grow. Re: your last point, I agree in principle but we are working on a product at large scale (>3M MAUs), so specialisation is necessary since the code base is so huge.
    – user17129
    May 12, 2015 at 18:45
  • Sorry I wasn't clear. It sounds like the backend engineers are developing in a completely separate code-base (I assume a they are creating a set of services or something like that being consumed by the other teams. You could simply add their stories to one team's backlog, but it's likely to make their velocity chaotic and may make it harder to predict if they will have contention meeting the needs of both teams. My question was if there are any benefits to doing that in your case that would outweight the problems with it. If not, I'd recommend them having a separate backlog.
    – Daniel
    May 12, 2015 at 19:04
  • Ah thanks for the clarification. Yes, the backend engineers are developing in a completely separate code-base. Regarding integrating their work in the mobile teams' sprints,I guess the benefits is that it keeps teams in sync, as we don't create "stories" for them, but rather "backend subtasks" which are part of the larger mobile user stories. And we don't estimate subtasks. So to a certain extent, what we're doing today is that we're integrating backend work as part of a mobile sprint, but not estimating it as part of the mobile team's velocity. Just wondering if it's the right way though.
    – user17129
    May 12, 2015 at 19:09
0

Why are you trying to incorporate backend work into your teams' velocity estimate? Is there a deeper problem you are trying to solve?

Ideally your stories are a vertical slice of functionality (regardless of how many code bases). So you would have 1 user story for iOS and one for Android that incorporate both front-end and backend tasks. Each story is story pointed to reflect the complexity of the entire vertical slice. In this model your front-end and back-end resources would have to agree on a story point estimate.

I could see the above being problematic in your scenario as your back-enders are split across 2 teams. Shared dev resources across scrum teams is generally not recommended as it makes dependency management harder, promotes context switching, and complicates estimation practices. Ideally you would have a dedicated back-ender as part of each team.

Consider what works best for your teams. While Scrum proscribes vertical slices, the greater value in being Agile is to force continuous or iterative planning, estimation, and discussion about upcoming work.

It may make more sense to create stand-alone backend stories in both teams' projects so that front-enders have story-level visibility into when backend work is nearing completion. This approach is generally a no-no in scrum since you may be creating interdependent stories within an iteration, but if it helps your teams' stay on track and pro-actively communicate about their workflows/internal dependencies it may be worth considering.

Improve this answer

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.