Scrum Team Composition: The Ideal Team Structure for Agile Development

Skip navigation
Agile Team Structure

How to Structure an Agile Development Scrum Team

How to Structure an Agile Development Scrum Team by Jasper van der Hoek

Although it’s one of the most widely adopted Agile practices in the world, not many know that Scrum got its name from the rugby term.

When you consider everything Scrum and rugby have in common, it makes sense. Both the Agile framework and the game are centered around teamwork. Team structures consist of a small group of people, and everyone has a crucial role to play in the achievement of a mutually understood goal — whether it’s to win the match or deliver a functional software application.

The best way to succeed with the Agile framework is to sort out your Scrum team composition. Continue reading for a look at who is on the Scrum team, best practices, and tips.

The ideal Scrum team structure

There are three major roles that play a part in the Scrum Team: Product owner, scrum master, and developers. Stakeholders and the business are also involved at varying degrees with most Agile projects. In larger enterprises, there are usually several business team members involved in the development process.

The size of a Scrum team

A Scrum team should consist of less than 9 people. For large enterprise projects, the ideal Scrum team size is 7 people (product owner, scrum master, and 5 developers). Smaller projects typically consist of four team members (product owner, scrum master, and 2 developers). Teams smaller than this wouldn’t technically be Scrum, as there would be a lot of overhead with all activities.

Scrum team tip: Keep your team simple and consistent. Don’t try and start your first project by inventing new roles or adding temporary team members. That only creates confusion around expectations and responsibilities, which introduces risks.

Members of a Scrum team

Product Owner

The product owner is responsible for defining the direction of a project. They have a clear understanding of what the business and users need from the product being developed, and they communicate these needs to the Scrum team.

Product owners make sure that the product being developed delivers maximum value for the business and users. This role also prioritizes work and manages the product backlog to move production along.

Related Reading: 5 Must-Have Product Owner Skills for Agile Application Development

Scrum Master

The scrum master makes sure the team follows Agile best practices and is in charge of addressing and removing any productivity blockers team members may experience. Essentially, the scrum master is the authority when it comes to Agile and Scrum.

Scrum masters are supportive types of leaders. They help product owners define the product’s value, plan work, and manage the backlog. They also help the developers self-organize and stay productive.

The development team

The development team is a group of people with the skills needed to build the product as envisioned by the product owner. The team doesn’t always include just developers; architects, writers, designers, and other specialized roles are also considered part of the development team.

Developers self-organize and are the authorities of their domain when it comes to determining how work with be performed and planning the backlog. As a Scrum rule of thumb, collaboration is involved in their day-to-day roles. They determine how to perform the work to create the product and work autonomously to manage and complete their work.

The business

Many enterprises work closely with the business team to gather and clarify organizational requirements for the product in development. The business team has experience and knowledge that can be extremely useful to a development project, but they are not considered an official part of a Scrum team. Instead, a representative from the business team — sometimes called the business owner — acts as a sponsor for the Scrum team.

Subject matter experts (SMEs)

From the Scrum team’s perspective, an SME is a person who possesses crucial knowledge that the team needs for a successful product delivery. For example, if you are building a new app to automate the invoicing process, your SME might be someone who is an authority in the billing or finance department. They will know the ins and outs of the invoicing process and can offer their expertise to ensure that the new app serves both business and user needs.

The Scrum team might need SMEs for different purposes and at different times, but they are all expected to answer questions and perform tasks to improve the product. During planning meetings, you can identify when information or actions are expected from the SMEs, and a Scrum team member can follow up with the SME to complete the action on time to prevent delays to product delivery.

SMEs are also considered stakeholders, but not all stakeholders have to be SMEs. A team member of one Scrum team can even be an SME for another Scrum team. But remember: an SME is not part of the Scrum team. And as such, this person cannot be held responsible nor accountable for any work they do for the team.

Related Reading: The Road to Adopting Scrum – Preparing for Your Journey

5 features of a successful Scrum team

Below is a list of key characteristics that are important to consider when creating your Scrum team.

1. Self-managing

The members of each Scrum team decide how the group will work together. Each member is equally important (no hierarchy), but responsibilities are clearly defined. This means that each team member should get an equal opportunity to voice their opinion. Together, they can then form a solution.

Ultimately, the product owner gets the final say about prioritization, but all other discussions are guided to a solution everybody agrees with by the scrum master.

2. Co-located

Scrum is all about close collaboration. Ideally, the entire team would be sitting in the same room so that there are no barriers (no matter how small) to communication. When team members are spread out over different rooms, locations, or time zones, it is normal for people to postpone their interaction.

3. Dedicated

Every member of the team should be assigned to the project full time, as any distraction will just delay work. Focused work is far more effective than switching between assignments or dividing your attention between two projects. Being dedicated to a single project is also the best way to take ownership and responsibility, which allows for better self-management.

4. Long-lived

Avoid making frequent changes to your Scrum team structure. New Scrum teams take time to adapt to each other, and changes even between projects will require time for the team to learn to work together.

5. Cross-functional

The team should possess the specialized knowledge required to deliver a working product. This includes team members with expertise in development, quality assurance, user experiences, integrations, and other aspects.

Scrum team tip: It isn’t always realistic for Scrum team members to have especially detailed knowledge about integrations with other systems. In this instance, you need to make sure that your team has access to all the knowledge they need. Depending on the size and complexity of the project, it might make sense to include the integration expert, QA-er, or UX-er as a full-time Scrum team member. But if you’re working on a small Scrum team, introducing those experts would create too much overhead. In those instances, you need a subject matter expert (SME).

Wondering how low-code fits in? See how the Mendix low-code Platform incorporates the tools Agile and Scrum teams need to succeed: 

 

The easiest way to start adapting Scrum is to have all participants in the project follow Scrum by the book. This can be a difficult change, but it offers the most clarity for everyone involved. Making changes in anything from day one is not a good idea. Change should happen based on lessons learned. Scrum works for most organizations that use it so why not for you? Improving comes after trying it out first.

This article was originally published on October 26, 2017, and has been updated to include the most up-to-date information.

Author