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:

Master of Agile – Agile Scrum Tester With 59 Seconds Agile (Video Training Course)

Introductory Offer: Free Course

Master of Agile – Agile Scrum Tester With 59 Seconds Agile (Video Training Course)

What is this course?

This ‘Master of Agile – Agile Scrum Tester With 59 Seconds Agile (Video Training Course)’ provides an in-depth understanding of the Agile Scrum Tester roles and responsibilities

You will explore the Agile Scrum project life-cycle, including how an Agile User Story is created, to how we know when it is ‘done’

This course is aimed at those with or without prior knowledge and experience of the Agile values and principles

During this course you will learn the tools needed to succeed as an Agile Scrum Tester

What will you learn?

You will gain an in-depth understanding of the Agile Scrum Tester roles and responsibilities, and you will be able to

  • Fully understand the role of the Agile Scrum Tester
  • Understand the roles involved in an Agile project
  • Create an effective Product Backlog
  • Effectively participate in Scrum Meetings such as the Daily Stand-up, Sprint Review and Retrospective
  • Identify the roles involves in the Scrum Team
  • Fully understand the role of the Agile Scrum Developer
  • Understand the roles involved in an Agile project
  • Create an effective Product Backlog
  • Effectively participate in Scrum Meetings such as the Daily Stand-up, Sprint Review and Retrospective
  • Identify the roles involves in the Scrum Team

What topics are covered within this course

You will cover the following topics during this course:

  1. An Introduction to Agile Project Management (Tester)
  2. The 12 Agile Principles (Tester)
  3. Introduction to Scrum (Tester)
  4. Scrum Projects (Tester)
  5. Scrum Project Roles (Tester)
  6. Quality in Agile (Tester)
  7. Acceptance Criteria and the Prioritised Product Backlog (Tester)
  8. Quality Management in Scrum (Tester)
  9. Epics and Personas (Tester)
  10. Planning in Scrum (Tester)
  11. Scrum Boards (Tester)
  12. User Stories (Tester)
  13. The Daily Scrum (Tester)
  14. The Product Backlog (Tester)
  15. Review and Retrospective (Tester)
  16. Validating a Sprint (Tester)
Translate »