Building an optimal-sized scrum team for a product can be challenging. Here are some pointers to help
As per the specification given by ScrumAlliance, a scrum team consists of 5 to 9 team members who may belong to different functional roles. This is the general guideline and not a rule. Many organizations struggle to come up with the right number of scrum members.
With so many thought leaders who have practiced scrum for decades, we can find a lot of different arguments. The truth is that there is no one-size-fits-all answer, as the correct scrum size needs to be worked out based on the type of work. Based on my experience working with several consulting and product companies, I’ll try to provide my take on various aspects of defining scrum size.
Project vs Product is the most fundamental differentiator in decision-making. According to PMI, a project is a temporary effort to create value through a unique product, service, or result. Since it is a temporary effort, the scrum size is usually the minimum number of people required to complete the work in the planned time frame. This is how most consulting companies create their scrum teams.
Budget and billing also play a part in deciding the scrum size for contract projects. In my opinion, the concept of scrum doesn’t even apply to short-term project teams, but it is a buzzword used by such teams to be called agile.
When we talk about product teams, there are a lot of factors that need to be considered. Here we are talking about static scrum teams intended to stay together for longer. I have seen several variations of product scrum teams at different companies. Some examples are having multiple small scrum teams (3–4 people) for a product, mid to large module-based scrum teams, large scrum teams owning multiple smaller components, etc. Let’s discuss the reasoning behind some of these variations.
Small Scrum team (3–4)
Some companies like to make small, focused teams work on specific features. If a product has two or three features planned, they divide the team into two or three small scrum teams. Another example where a small scrum team is created is if the work develops small utilities, services(APIs), or components (eg, UX widgets, libraries, common components, etc.).
This appears to be an efficient way of delivering the product but doesn’t align with the essence of Scrum. Some general observations on small-sized scrum teams:
- A small scrum team may compromise on certain roles/skills like product owner, test engineer, or automation/deployment skills.
- A small scrum team may lack enough expertise in the team for quality checks like peer reviews and/or extended verification/testing.
- There is less knowledge sharing and hence no backups for anyone.
- This eventually creates the “bus factor” situation as every individual knows only about their contribution.
- Small teams can be stressful if there is even one difficult personality in the team.
- There is less ownership of work if the team is temporary.
- Post-development support can be challenging as people get re-assigned.
- There is no time for the personal growth or training of team members.
- Even a slight bit of attrition or unplanned absence can destabilize the whole planning.
- Scrum ceremonies appear less meaningful due to the lack of enough voices.
If the individual contributors are outnumbered by people with ‘manager’ titles (Eg, Scrum Master, Engineering Manager, Product Owner, or Product manager) then it is not a healthy balance for the team.
Large Scrum teams (8-10)
Most user-facing application teams create larger scrum teams, especially if they try to create self-contained teams. Filling up roles for each architectural layer and related functions like frontend developer, DBA, deployment scripting, etc., adds up to make it a good enough sized team.
Some companies, like the ones in the business of enterprise software products, divide teams into functional modules. You may hear teams like Order management, Online Account creation, or patient accounting. Here the team size depends on the depth of the backlog and the product roadmap. Here are some points to note for large scrum teams:
- Larger teams are usually static teams, planned for a longer duration.
- With more people, there is more inflow of ideas and brainstorming.
- More expertise is available as there is no overlapping of roles.
- There can be backups for every skill set, making team more stable.
- Cross-training of the team is possible by spreading knowledge.
- Shared ownership of the product can be established with more collaboration.
- Scrum ceremonies take up longer with more people.
Of course, there is no easy answer, but I would like to reiterate some fundamental points that should not be ignored while creating a scrum for product teams. These are the things that can help you come up with an optimal number for the scrum team.
The management team should review the product roadmap, including the client commitments and budget, to develop a team size that can have a consistent flow of work for a long duration. As mentioned above, if it’s a bigger product, multiple scrum teams can be created based on factors like functional requirements, features, or dependencies.
If the product or solution is small, the effort should still be made to have a standard size team that can own multiple work outputs. The goal should be to create a cohesive group that owns the product as a whole, and if it is too large to manage, then divide it into smaller scrums.
The other important consideration should be to fill up all the required roles so that there is no external dependency or overlapping for day-to-day work. A team should have all the skillset required to deliver a vertical slice of work output. This means the team can handle all kinds of work, from frontend development to DB design to creating deployment scripts. People not wearing multiple hats results in higher productivity and high-quality deliverables.
Quality Over Speed
The team should have enough people to review and verify each other’s work. This will ensure that none of the quality measures are skipped due to a lack of resources. Multiple eyes on each work output are important, whether it is code review, verification, or validation. None of these steps should be considered overheads as this time investment in quality results in delivering better products.
Stability over Efficiency
A collaborative team with distributed knowledge can be a much stronger and more stable team over time. Such a team has multiple experts, enabling it to scale easily if the need arises. Therefore it is important to ensure enough people cross-train in every aspect of the deliverable. It may mean a slight impact on efficiency, but it should pay back in the long run. Minor changes in the team due to attrition or reassignment would not impact the team velocity.
Strive for balance
Try to make a balanced team in terms of skill set and experience. The mix must be such that backups can be built for every development aspect. This ensures there is no “critical” dependency on anyone, and no one is overloaded with responsibilities. The balance is the key to creating a sustainable team that isn’t stressed about work all the time.
Once you have thought about the points mentioned above, you will get the optimal size for your scrum.
I recommend always going on the higher side of the recommended scum size (greater than five). If the work on one product is not enough for a standard size scrum, it is better to work on multiple products than to create a small scrum team bound to struggle. This will keep the team intact with a variety of work, more opportunities for growth, more bonding, and enough contingency plan. After all, the scrum team is about people!
Every team and every product is different, and the success of each scrum depends on the team members. The more you invest in the team, the better it becomes, and all the investment pays off in terms of the quality of your product.
If you try to save with a smaller team size, it does not pay off in the long run. The team gets no breathing time with added responsibilities, feels more pressure, and loses motivation. The basic principle behind the success of Scum is the emphasis on people, collaboration, and human interactions. This is why any time spent with a standard-sized team in discussions or scrum ceremonies is an investment that pays off one way or the other. If you have any other thoughts on this topic, I would love to hear them in the comments.
Thanks for reading!