I've recently joined a company where I'm working as the scrum master on an agile development project building a web app.

The team is just about to be the maximum size for an agile team (expecting 9 next week). We have talked about potentially splitting the team into two teams, not so much to shorten standups (which aren't excessive at the moment) but to stop people from being completely bored in sprint planning sessions (which again aren't excessively long).

There are two very distinct layers to the project - high technical backend dev (like seriously complex), and UI design/build/integration. It seems that when the backend guys are talking technical the UI guys zone out, and vice versa. It seems like the logical way to split the team if only to be more time efficient, but I have one massive reservation in that all I might really be doing is reducing collaboration and knowledge sharing. The two teams just won't really have a good idea about what the rest of the team are building.

Does anyone have any experience in dealing with something like this?

  • Do the teams have leaders?
    – superM
    Commented Aug 14, 2013 at 7:23
  • Having multiple teams is a trade off. A big team (even bigger than 9) can be ok, compared to the overhead of scrums of scrums etc. It just requires a little more discipline in the stand ups Commented Aug 14, 2013 at 11:44
  • Yes, they would both need to have leaders. Currently one of the teams wouldn't though. Commented Aug 15, 2013 at 4:58

6 Answers 6


That is unfortunate the UI guys don't care about the detail of the complex backend work. This sounds more like a discussion topic for a retrospective. Splitting the team along discipline would set a dangerous precedent, how soon would it be before the Requirements folks begin zoning out and not caring about what the UI guys are doing and ask for their own team.

I have always been in favor of vertical slices for my teams. UI should listen to what the technical folks have to say, as they are the very folks who could help to make their job easier (Oh, that widget is going to cause you to do this, what if we used this widget instead).

Personally I would focus on the issue of the UI guys zoning out first, then once that dysfunction has been resolved, discuss how to best split up the teams. I am not trying to vilify the UI guys, perhaps the technical folks could also do more to make their discussions more relatable to for the UI guys.

As others have said, the team should be allowed to self organize to determine the new structure. Past experiences have taught me self-organization can only really work when everyone is concerned for the team, rather than their own discipline or interests.


  • "I have always been in favor of vertical slices for my teams" +1, me too! You can always have some UI experts, or DB experts for polishing those sections to perfection, but on the whole, vertical slice development is always my preferred way.
    – ozz
    Commented Aug 16, 2013 at 9:28

It is indeed a good idea to split the independent parts of the team into new teams. In larger project, it is almost impossible for the developers to be closely familiar with the whole project, so the splitting is still present formal or informal.

Each of the new teams should have a team-leader/technical manager, who has a solid knowledge about the scope of their team and who is familiar with other teams' work as well.

After that each team can have separate scrum meetings, and the leaders of the other teams can be present. This way you will reduce the number of "bored" people, but still the teams will know what others are working on and will be able to successfully collaborate.

The collaboration becomes more important if the scopes of the teams are intersecting or one team depends on the other. But again there is no need for the whole team to be present _ the team-leader can coordinate the collaboration.


When splitting up teams I'm always trying to keep in mind the fact that a team needs to be able to deliver value to the customer. In your case it would be having both backend and frontend developers in the team.

  • 1
    In large projects its hard to impossible for one team to work on every aspects of a product, and typically that is not necessary. So I wouldn't agree that every team by itself should be able to bring immediate value to the customer _ customers aren't interested in the UI or the backend, they need the whole project. On the other hand, UI and backend are parts of the product and the teams working on those bring value to the product.
    – superM
    Commented Aug 14, 2013 at 9:53
  • 2
    Well, we definitely disagree. The question was for an agile team. For me, the business value for the user of a working backend without frontend is 0.0 The same applies to a working frontend without backend. And what will the individual teams demo on the sprint review? On top of that, it will be difficult to align the work of both teams.
    – user99561
    Commented Aug 14, 2013 at 10:14

A key aspect of Scrum is self organizing.

I suggest that you discuss the question with the team, and let them solve it.

Your concerns are all well-founded, but remember that as the Scrum Master, your job is to coach and facilitate. So ask them how they will solve these issues. They will own the solutions, and make it work.

I would add: in general, cross-functional teams are the way to go.

  • This is what has been suggested by some of the team members, but I'm not sure it is the best thing to do. Hence the question! I think it comes down to the fact that the UI guys don't care about the detail of the complex backend work. Commented Aug 15, 2013 at 4:57
  • IMHO I think this "self organizing" thing has gone too far. Commented Mar 12, 2021 at 4:51
  1. How far is the front-end from the backend? Predictably, splitting is a good advice only if the distance is too far.

    • If the backend talks about database schema, this is not too far. Both front-end and backend needs to listen to discussions about database schema.

    • If the backend talks about sharding, memory caches, disk latency, etc., then this is a bit too far (where the backend focuses on mechanical sympathy and optimization, while the front-end focus on humanly aesthetics).

  2. Is there a stable and unambiguous programming interface between the front-end and the backend?

    • By stable and unambiguous, it means the users of that programming interface (the front-end developers) will not be bogged down with changes, and will not need to read walls of text in order to learn how to use it correctly.

    • The backend team need to provide a good API, and a mock implementation early on, and only after that start the real development.

    • This is not to say the API should be set in stone. This is just a mitigation of the consequence for splitting a team into two.

  3. Why do so many agile articles recommend having vertical slices? Here is some background information:

    • Most agile articles actually recommend avoiding backend work, from a cost perspective.

    • Also don't forget that a fraction of agile articles had the implicit bias toward startup companies.

    • And don't forget the harsh reality of marketing - most customers only pay for the front-ends.

    • Backend work tend to be costly and had slow payoff. Unless a company is already established for the long run and is generating a decent profit, it is better off to "outsource" backend by sticking to off-the-shelf technology and open-source libraries.

    • Most agile articles also recommend implementing the front-end so that it can survive a backend switch. This advice goes hand-in-hand with the previous one: if the off-the-shelf technology does not meet all requirements, try another one.

  4. Practices that can mitigate the bad consequences from splitting a team

    • Stable back-ends
    • Stable API
    • Low defect rate back-end
      • Reason: to avoid frustration
      • How: unit testing
      • Doesn't mean: performance or optimization; it just need to be functionally correct.
    • Continuous integration
    • Transparency in communication, progress, and decision making
    • Encourage informal discussions across the two teams
    • Encourage team members (those who don't zone out) to attend the meetings of the other team.
    • Set up occasional joint meetings, and joint retrospects
    • Other team-building activities

Like others, I would definitely suggest going with vertical slices. These are sometimes referred to as "Feature Teams". I would recommend reading on the pros/cons over at the Scaled Agile Framework site: http://scaledagileframework.com/scaled-agile-framework/team/features-components/

At first, when you split, your Product Owner and SDF Master may be able to handle the Release Backlog for both teams as well as individual backlogs for each feature team. As you grow, however, you will likely need to implement a product features backlog which is then fed into multiple agile teams release backlogs. Once you scale to that level, you will likely need a separate team managing the features backlog and then bringing the features down to the individual teams for implementation. In that structure, you may have something like this:

  1. Agile Team 1: SM, PO, Cross-functional team. Has own team backlog for their stories.
  2. Agile Team 2: SM, PO, Cross-functional team. Has own team backlog for their stories.
  3. Program Management Team: Product Manager, Release Managers, Enterprise Architects. Has own program backlog of higher level epics and features that will be organized, analyzed, and then fed down into the teams.

The SAFe website has a lot of cool stuff for organizing larger teams, and some might be helpful for you as you move to a larger scale of teams-of-teams.

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.