Optimal Size of a Scrum Team

Optimal Size of a Scrum Team

A typical scrum team needs to have the necessary skills to carry out tasks efficiently while taking care of product quality and productivity. Whether you are working in a small startup or a large company, you are more likely to come to a point when you have too many members in one team.

That's why identifying this issue early on can save you a lot of trouble. Otherwise, you might end up with an inefficient team, which is the worst-case scenario. According to Jeff Bezos, the world richest man and the owner of Amazon, you should apply the "two pizzas rule", meaning you should be able to feed your scrum team with two pizzas.

However, different organizations and companies require teams of various sizes. Therefore, in this article, we will be addressing the recommended size of the scrum team and see how your company fits into this math.

Responsibilities in scum teams

By design, agile teams are responsive and flexible. It's important to note that the agile team working in scrum has three primary responsibilities or roles:

Product owner – in most cases, a key stakeholder or an executive, the product owner has a vision of how the end product should look and how it will fit into the company's long-term goals. This person needs to manage communication efforts, notify the team about significant developments, and implement high-level changes when necessary.

Scrum master – this role is similar to a project manager. They guard processes, ensure feedback, mentor junior team members. Scrum masters also monitor day-to-day functions, check in with team members, keep the scrum board updated, and ensure that tasks are completed on target.

Team members – they are a crucial part of this process, videographers, copywriters, front-end engineers, back-end engineers, you name it. Team members have different roles in the scrum team, and they are responsible for getting milestones and projects done on time and in excellent quality.

Agile teams typically blend Agile methods

Teams apply different agile practices, primarily based on XP or extreme programming, Kanban, and Scrum, to boost their performance. On the other hand, to make sure they fix the problem, team members use design thinking.

Also, Build-In Quality practice is a method teams use to drive quality and discipline content creation. Continuous integration, test–first, standard, pair work, and collective ownership help keep things lean and inject operating efficiency and quality directly into the process.


The majority of teams use Kanban to envision and visualize their work, establish WIP or work in process limits, use CFDs or cumulative flow diagrams to illustrate principal opportunities and bottlenecks for enhancing throughput. We should mention that for some teams, Kanban is the primary practice. This is mainly because commitment elements of scrum and planning may not apply as efficiently for demand-based workloads. Also, Kanban is popular for teams in which activities change frequently.

Are small scrum teams better?

According to some, smaller teams can make quicker decisions, be more agile and move faster than their larger counterparts. But does being smaller mean better at the same time? It depends on the situation, and all teams, bigger or smaller, have their struggles, which means determining the size of an agile team requires a detailed approach.

Scrum teams should be result-driven, lean, and small. Some experts say the scrum team size needs to be up to six people.

One significant difference that may be an advantage is that smaller teams can develop faster and learn faster. They can repeat this learning process multiple times until they get it right. Even if they fail, they can quickly figure out their mistakes, learn from them, and move forward. In other words, this speeds up team development.

Another thing worth mentioning is greater transparency, which increases trust among team members and forms a perfect environment that helps teams develop real solutions that matter. Transparency is closely linked to accountability and is an excellent equalizer for small teams.

The Big Book of Team Culture

This article is just a small part of our Big Book of Team Culture. Get your hands on this free ebook and learn what makes a great team, how to improve teamwork, what it means to be a leader in a modern workplace, and how to create positive team culture - all in one place.

*Enter your email address and subscribe to our newsletter to get your hands on this, as well as many other free project management guides.


Without these two factors, small teams cannot move forward and accomplish their goals. When there is more transparency, they will address problems quicker and apply solutions faster.

In smaller teams, members feel like they are producing meaningful work and making a difference. Also, it's easier for individuals to see the impact they're making because smaller teams have that familial feel, which is quite challenging to accomplish in larger teams.

How to make Scrum work for small teams

Finding a balance between clients and ensuring your team has enough space to work is quite a challenge. Scrum methodology supports four meetings: sprint planning, daily standups, review, and retrospective. When you add client meetings on top of everything, you are disrupting the focus on getting the work done.

Simply put, the number of meetings can significantly affect the productivity of your team. You can expand the scope of communication, which will reduce the number of sessions, but still ensure that key stakeholders are still notified about all changes and the project's progress. You can either use messaging apps or resort to an in-house software solution.

It takes time to understand communication patterns, but once you get a hold of them, you will be able to map out when, who, and what is being communicated. Implementing scrum and other agile methods is all about making compromises and adjustments.

Occasionally, it's best to resort to a hybrid approach that combines multiple methodologies and sometimes to do everything by the book.

Can one person be involved in multiple scrum teams?

This is a question we encounter all the time. While scrum doesn't have a rule about one person being on multiple teams, it implies a couple of questions. For instance, can one person effectively be a member of multiple scrum teams, and should that person accept such responsibility?

You will often see people split across teams. Occasionally, they will face numerous challenges, one of them being increased complexity for collaboration and communication. When a team member isn't committed and focused on one scrum team, that individual needs to make daily choices regarding when to be available, which team to choose, and how much time to spend with them.

The second challenge they may face is a quality issue and loss of productivity. A team member must switch context all the time, stopping one activity and picking up another for a different scrum team. After some time, this might lead to a loss of energy and losing the ability to remember where you left off and what to pick up now. Individuals will feel pressured, which will affect the quality of their work.

We have one more thing worth mentioning, and that's delays in value delivery. Quality issues, loss of productivity, and increased complexity all lead to delays in value delivery. You will often get things started, but they don't get finished, at least as early as they should be. The more things you work on at any given time, the longer it's going to take you to finish them.

Close