Using an Agile project management framework like Scrum does not avoid the problems of right-sizing the team. What do you do when you need to increase the numbers of people involved? When is the team too big? How to split an existing Scrum team? In this article, Cynthia Kahn provides some tips on how to assess and manage the growth of Scrum teams.
Author: Cynthia Kahn, GSD Mindset, http://gsd.guru/
You May Need to Divide Your Project into More than One Scrum Team
In Chapter 1 of the GSD Scrum Handbook, we talk about the size of the GSD Gold Scrum team. What is the right number of team members? The Scrum Alliance recommends a Scrum team size of no more than 9 members. At GSD Mindset, we also recommend organizing a Scrum team with all the skills to complete quality work valued by the customer: Product Owner, Scrum Master, Tech Lead or Architect, Business Analyst (to help Product Owner write Stories), Programmers and Quality Assurance (QA) testers.
A Scrum team size of 9 members may be optimal for Scrum, however your project may need a bigger team to complete all the required work on time. In Agile projects as well as Traditional projects, we face the same Time-Scope-Budget triangle constraints. When Time is fixed, sometimes upper management agrees to add Budget, and then your boss goes out and hires more team members.
How Do You Know When the Team is Too Big?
One indicator that helps determine whether or not a Scrum team could be too big is the length of stand-up. If your team sticks to the constructs of stand-up and they cannot complete the meeting in less than 15 minutes, the Scrum team may be too big.
Large Scrum teams developing lots of features that cross multiple business boundaries can be another indicator. If you notice Scrum team members stop paying attention half way through stand-up, retrospective or sprint planning, then dividing the team is a good way to speed up those meetings up and keep everyone engaged.
There are lots of reasons why teams get unwieldy and difficult to manage. If you’ve got 10+ team members on the same Scrum team and you feel like the team is becoming inefficient, it probably is inefficient.
How Do We Split the Scrum Team?
Identifying the need to split one team into two teams is easy; deciding how to divide the teams is not always easy. We at GSD Mindset believe all the roles listed above are required to form a competent team. We want you to continue this practice as you plan for and hire new Scrum team resources.
When management wants to get more stuff done, their first thought is to hire more programmers. However, if you double the number of programmers without hiring QA testers, QA becomes a bottleneck. If you don’t hire another Business Analyst to help the Product Owner write Stories, grooming and sprint planning can get delayed.
Yes, you can share the same Product Owner, Scrum Master, Tech Lead and Business Analyst across 2 teams that share the same Backlog when you add 2-3 new programmers. We do encourage you to keep the ratio of programmers to QA testers at 3:1 if possible.
Of course, your application may require a different mix of players. The important takeaway here to remember that as your Scrum team grows and splits into more Scrum teams, keep in mind: The correct mix of team players ensures maximum throughput.
How Many Scrum Teams Can Pull from One Backlog?
Scrum teams with shared Backlogs continue to share the same grooming sessions, sprint planning and retrospectives. Those meetings may still be unwieldy, because you only really divided the development and QA aspect of completing Stories. Consider this before you decide to divide and still share.
I once worked successfully with 3 Scrum teams pulling from a shared Backlog. The combined team supported multiple applications and the Engineering Manager wanted all the programmers to have the knowledge to work on any one of them, depending on the needs of the Product Owner. Keeping Stories written and groomed became challenging, so each Scrum team added their own Business Analyst to help write Stories. The burden fell on the Product Owner to ensure the right mix of high-priority Stories were ready for sprint planning. Our original Scrum team organically grew from 1 to 3 teams over the course of 2 years, with the same Product Owner and Scrum Master, so they were experienced enough to handle a Backlog with hundreds of Stories.
I would not recommend 3 teams sharing one Backlog for those new to Scrum.
I would never attempt to manage 4 teams from a shared Backlog.
How Do We Divide the Backlog?
If you divided your functional requirements into independent feature sets or Epics as described in Chapter 2 of the GSD Scrum Handbook and you include Epic as one of your Story attributes in your agile project management tool (like JIRA or VersionOne), then you can easily start a new project and divide the Backlog. If not, then you need to properly attribute your Stories with an Epic.
If you are dividing 1 Scrum team into 2 Scrum teams, the Product Owner, Business Analyst and Tech Lead should review the Epics and organize them so the 2 sets of Epics have the least amount of overlap. The 2 Scrum teams must be organized so they can independently complete their Stories.
After the split:
* Each Scrum team must be able to close Stories without relying on the other Scrum team to complete any work
* Cross-team knowledge sharing is appropriate.
* Cross-team pair programming is not appropriate.
How Do We Divide the Team?
Agile is about self-managing teams. As tempting as it may be for the Engineering Manager or Product Owner to divide the Scrum teams based on tribal knowledge about the Epics in each Backlog, don’t do it! Let the teams divide themselves and pick their own team members.
Organizing for success is not always easy.
Think about what stuff needs to get done and think outside the box.
About the Author
Cynthia Kahn has experience managing both agile and waterfall projects. Cynthia is co-author of the GSD Scrum Handbook and co-founder of the agile consulting company GSD Mindset, where she teaches Scrum in 1 Day and coaches teams as they transition to agile. This article was originally published on http://gsd.guru/2017/09/24/how-big-is-too-big-for-Scrum-team/ and is reproduced with permission from GSD Mindset.