What to do if your scrum teams becomes too large

Agile leadership leadership organizational design Scrum what to do if your team is too large

What to do if your scrum teams become too large?  Split it into smaller teams.  Keep reading to learn how to determine if you can or even should split your team.

Do you want to know what to do if your scrum team becomes too large? If so, all you need to do is keep reading this free tutorial and you'll learn our proven five-step process to keep your scrum team is a perfect size.  We'll answer the question, "if scrum teams become too large they should..." diagnose, prescribe, align, split, then monitor.  

Level up your agile and get professional training.

Scrum Master Certification

If Scrum teams become too large they should split

    Before we get started let's make sure we all understand Scrum the same way.  Scrum is the framework that consists of roles, events, and artifacts as described in The Scrum Guide.  

    If you haven't read the Scrum Guide.  That's your next step or none of what we're about to go over will make sense.  

    Level up your agile and get professional training.

    Scrum Master Certification

    OK, now, on to answer the question, " if scrum teams become too large they should..."

    Executive Summary

    While it's tempting to say that every scrum team that gets too large should simply split and move on, that's an overly simplistic solution.  You must first understand why the team has grown to that size and if the team could split and still maintain cross-functional capability.  

    Assuming you've diagnosed the situation and that the very large team can successfully be split into two or more smaller teams, that's what you should do if your scrum team becomes too large.

    If your team can't be split into two independent, cross-functional teams and further diagnosis will be required to avoid poor outcomes for your scrum teams.

    Step One - Diagnose the Problem

    Before you jump into the problem-solving mode it's important to diagnose the problem.  Begin by talking to each member of the team and asking questions such as, "is your team cross-functional?" This is the most important question because cross-functional teams are proven patterns for high performance.

     A cross-functional team is a team that is able to complete all the work necessary to ship their product without external assistance.  Cross-functional teams are faster and produce higher quality work because they are able to complete all necessary tasks without having to go outside of the team and rely on external dependencies.

    It's always easier to do work if you don't have to rely on others.

    "what product does your team create?

     This question is critical because understanding the product will help you diagnose if the team is all working on the same product or not. It's amazing how many times a single team will actually be creating three or four separate products.

    In such cases, it's easy to split that team into multiple teams by segmenting them by the product that they are creating.  Then, each scrum team is only working on one product.

    "what customer does your team serve?

    This question may seem silly, but it's critical to understanding the situation. Here's why, many teams will create one product that serves different customer statements. You can oftentimes separate the large team into multiple teams and segment the team members by which customer they serve.

    This process begins by understanding what customer each team is serving.

    Step Two - Prescribe the Solution

    Once you have understood the problem thoroughly by investigating if the team is cross-functional, what product they create, and what customer they serve you are ready to prescribe a solution.

    This solution should be tailored to your team-specific situation and take into account company culture.

    Is it acceptable in your company culture to dictate which people will be on which team? If yes, you can move forward confidently prescribing the solution do you think is best.

    If your company culture does not support unilateral decisions about personal assignments then you must be very cooperative during the prescribe the solution step of this process.  You must work with the members of the team and other stakeholders within your corporation to make sure everyone is aware of and has had input to your solution before prescribing your solution.

    Step Three - Stakeholder Alignment

     Stakeholder alignment is defined as discussing, coordinating, and arriving at a common solution across all stakeholders.

    In simple terms, making sure everybody's OK with your idea.

    This is the most important step in this entire process.  

    Without stakeholder alignment no matter how brilliant your solution is it's likely to fail.  You are working with people and people need to feel involved in the decision making process.

    The people who most often get this wrong or corporate executives who feel they can dictate corporate culture and policies without aligning their internal stakeholders.

    If you fail to do this properly you will sync morale, decrease team velocity, and increase the chances of high turnover within your company.

     If you do this correctly you are likely to have a successful implementation, abroad base of support for your ideas, and low turnover throughout your company.

    Step Four - Split the Scrum Team

    A team should be no more than nine people not including the scrum master and product owner. If you have teams greater than nine people it's likely they need to be separated into smaller teams.

    At this point in the process it's time to split up the teams. Focus on splitting up the teams to keep the most cross functional skills on the smaller teams.

    Look to align with the teams to the product they create and the customers they serve.

    While it's impossible to prescribe your solution, the principles I laid out above will guide you through many tricky situations so that you can arrive at a successful solution.

    If your strong teams become too large you must separate them down into teams of between four and nine people. 

    Step Five - Monitor The New Teams

    Once you have split the terms it's important to monitor this change.  Scrum makes monitoring team productivity easy by measuring velocity.

    Velocity is the story points completed by each team during the entirety of the sprint.  Tally the sprint points at the end of the sprint and this provides velocity.

    Monitor velocity from sprint to sprint to keep track of team productivity overtime. If team productivity takes a drop and stays low after the split, go back to the first step and begin diagnosing the problem again.

    If team velocity increases overtime then you know your original solution has been effective and you should continue monitoring team progress as a gauge of team health.

    Scrum mix monitoring productivity and management changes such as splitting up teams that have become too large simple.

    If you found this article helpful you might want to learn hot to become a Scrum Master.


    In this tutorial you learned what you should do if your scrum teams become too large.  We reviewed a simple but effective five step process to split your teams if they become larger than they should be. We reviewed the ideal size of a scrum team as being between 4 to 9 people.

    Are your Scrum teams too large?

    Are you frustrated that your daily Scrum takes 45 minutes each day?

    We can help?  Contact us

    Why should you trust this information?

    This post was written and checked by our staff writer, Jon H who is a Registered Scrum Trainer and Registered Scrum at Scale Trainer through Scrum Inc.

    Scrum Events

    Sprints typically last between one and four weeks, and they include several key events, including:

    1. Sprint planning: A collaborative event in which the team decides what work will be completed during the sprint and how it will be accomplished.
    2. Daily scrum: A 15-minute time-boxed event in which the team meets to discuss progress, identify roadblocks, and plan for the day ahead.
    3. Sprint review: A collaborative event in which the team demonstrates the work that has been completed during the sprint and receives feedback from stakeholders.
    4. Sprint retrospective: A collaborative event in which the team reflects on the sprint and identifies opportunities for improvement. Each of these events is time-boxed, which means that they have a set duration and are designed to keep the team focused and on track.

    Older Post Newer Post

    Leave a comment

    Please note, comments must be approved before they are published