The Scrum Team Size for Testers

There is one thing to know about Scrum teams: size matters. And testers would know this very well. If it’s too small, then it’s going to be challenging to meet deadlines. If it’s too big, then the team could get tangled up in dependencies and miscommunication. So what’s the right size, then? And how are testers affected with team size?

The Development Team, According to the Scrum Guide

First, let’s revisit how the Scrum Guide defines the Development Team:

‘The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of the product at the end of each Sprint.’

Note that the Scrum Guide calls the Development Team members simply as “professionals”. This is because Scrum does not recognise titles. While it definitely describes the Scrum team to be cross-functional, it also emphasises on how “accountability belongs to the Development Team as a whole”. So regardless of whether you’re a technical architect, a programmer, a data engineer, a business analyst, or a tester, you’re known in Scrum as a developer.

The development team is cross-functional and have the skills needed to develop the product. The Development Team are also self-organising. The Product Owner, the Scrum Master, and even the customers can’t tell the Development Team how to transform the Product Backlog into smaller, potentially releasable product increments. After all, it is the Development Team who have the skills and technical knowledge to make the product happen, and the organisation they work in should be conducive for them to form the synergy needed to come up with the best decisions for the team.

Even though the synergy needed to build the product will depend on things like trust, respect, and communication, the number of people involved is also a factor in making or breaking that synergy.

The Development Team Size

Before, determining the Development Team size for Scrum (and XP) projects would ensure that the number of Development Team members would be fall within the range of plus-minus seven – which would be five to nine. While that is a good guideline, the Scrum Guide now updated this and officially says that in a Development Team, there should be at least three developers and at most nine developers. This range is just right, as it allows the Development Team to be small enough to move quickly but cover enough work to build a potentially shippable product increment towards the end of the Sprint.

The problem with having fewer than three members is that the decreased interaction results to ‘less productivity gains’ or, in other words, less work done. On the other hand, having more than nine members simply requires ‘too much coordination.’

As you can see, having a good team size matters because the number of interactions among the team members affect the speed of building software.

Relationships Within the Team

A formula that can be used to determine the number of interactions or relations within the team is (N (N – 1)) / 2, where N is the number of people in the team. Using the range of ideal team sizes from earlier:

• If there are 5 team members within the team. That results to 10 combinations of team members who interact with one another.
• If there are 7 team members, then there will be 21 combinations of interactions..
• And if there are 9 team members, then there will be 36 combinations.

This formula supports the earlier statement from the Scrum Guide on how bigger team sizes mean more complex interactions among the members. In order for software development to be successful, those relationships must be strong and stable. Having a higher number of members makes it challenging for them to build relationships.

<– Continue Reading –>

Our Book Recommendations

We found these books great for finding out more information on Agile Scrum: