i hope the title is relevant; I find it hard to put to words so concisely.

The Teams

We have 3 teams each with their own backlog and focus (think systems team, web team, mobile team). The 3 teams have 1 of 2 partially overlapping sprint schedules, each of which is 2 weeks long. Also, each team has its own planning meeting.

The Problems

For a while each team was operating independently just fine, but now we're coming to a point where delivering stories depends on other teams implementing functionality.

Also, there is not enough work for some developers to focus on only one team.

The Ideas

I'm thinking we need to add an additional team for internal APIs so that features needs by other teams can be worked on without hopping teams mid-sprint. MY main reason for thinking this is good is so that velocity can be more accurately measured and represent the progress of the focused topic for each team. For example, the mobile team's velocity should only represent work done on mobile products, not server side APIs.

That's where I leave it. I'm hoping to get some actionable advice from what others have found effective with similar team setups.


  • How big are your teams?
    – Sven Amann
    Jan 22, 2014 at 8:51
  • Is there a common Product Owner?
    – Sven Amann
    Jan 22, 2014 at 8:59
  • team size: mobile=3, web=4, system=5. Product owner is basically the founders who guide feature development.
    – Brenden
    Jan 22, 2014 at 20:43

2 Answers 2


You've tagged your question as Scrum so I'm going to assume that is your methodology.

Scrum (and other Agile methodologies) prefers using user stories that are vertical slices. This means that your features are end-to-end, each delivered story is a working increment of software.

User stories should follow the INVEST criteria. The I means independent, you should avoid dependencies on these teams of other layers.

If your teams do not have the expertise to complete a feature end-to-end then you should consider re-structuring the teams. Change the teams to have at least one member from each layer.

The guideline for the size of Scrum Teams is 7+-2. Given that the total team isn't that big (3+4+5=12), you could consider merging all the teams together into one. Sometimes, the disadvantages of a large team are outweighed by the advantages in collaboration/communication.

However, two teams of six is probably better as it should be easier to manage and within the guidelines.

Which ever way you decide, by merging or re-organising the teams, you want people to work together on completing features. Having a team that can completely implement a feature will eliminate waste, because they won't be waiting for features from the other teams.

  • While we can't have each team be independent due to the product to dev ratio, your point on INVEST is a decent answer in the context of Scrum. We are considering some mix of kanban and scrum that would allow less dev locking (aka sprints). We'll see. Thanks for your advice.
    – Brenden
    Jan 23, 2014 at 21:05
  • 1
    Custom software methodologies are difficult to do, I would avoid diverging too far from Scrum. And I dont understand what, "due to the product to dev ratio," means Jan 24, 2014 at 11:30
  • Clearly there's a web team and a mobile team mentioned in the comments to the question. Those two certainly can deliver value and should remain. The third team mentioned "system" can't deliver end value by itself and should be split among the two others.
    – Sklivvz
    Jan 26, 2014 at 20:39

You should definitely not add another team to the process. It is hard to define APIs without having an implementation that shows what is required and it is even harder to implement a frozen API. You'll loose your agility in development because you fix things upfront. And you make inter-team dependencies worse.

Rearranging the team, as Dave already mentioned, is probably the best thing you can do. You could still measure the progress on mobile/web/system, because you know what has been done in which area. You can even track which team has achieved how much of the progress in what area.

  • As mentioned above, I think the real issue we're dealing with is blocking teams due to staggered sprint schedules. We're considering simplifying the teams and then replacing the 2 week sprints with milestone releases. Ideally, this will allow devs to pivot more quickly and reduce the amount of time other devs are blocked. Thanks for your feedback.
    – Brenden
    Jan 23, 2014 at 21:08

Your Answer

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

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