When speaking about multi-disciplinaire teams at DrupalCon Dublin, the question “What is the ideal Scrum team size” was raised by a number of people.
While I know Scrum prescribes an ideal team size of 6 to 9 people, November of last year we experienced that our team was becoming too big and decided to see what would happen if we split it up. In this blog I will explain the cons we ran into with a bigger team size and why this led to the decision to split our original team up in two separate teams.
Enough is enough..
In October 2016 our Scrum team had grown to 12 people. Excluding 2 interns, who we won’t count for the purpose of this blog because even without them the team was already too big. 😛 Our team consisted of:
- 1 Project Owner
- 1 Scrum Master
- 6 Back-end Developers
- 1 Front-end Developer
- 3 Designers and User Testing Experts
You can probably imagine that the size of our sprints where huge. Our velocity was +/- 300 points per 3 week sprint. The amount of issues that were listed in the sprint felt endless!!
This resulted in the following problems….
To make sure enough work had been refined for the coming sprint we had to plan extremely long refinement sessions. While under normal circumstances the entire team should be present for these meetings, so everyone has a clear understanding of the ‘Why?’, we weren’t able to include all 12 people in these sessions because that would mean the meetings would be even longer still. That we all have very strong opinions of course meant the meetings would never be short to begin with. 😛
We all agreed that splitting the attendees was not the way to go, but 12 people in the meeting was also a definite ‘no go’ for us. Additionally: during the sprint we’d schedule intake meetings with the people who would be working on a specific story.
Sprint planning sub-groups
We had a hard time discussing the stories that would meet our sprint goals. So we started to discuss them in smaller groups to create workable items. Unfortunately this (once again) resulted in not every team member having workable knowledge of every story in the sprint
Hard to have focus in the sprint
We were working on 4 different projects in 1 sprint:
- The Open Social Distribution
- The commercial/ marketing site where you’re reading this
- 2 Enterprise projects where the distribution was implemented including a number of custom features
- Since it’s hard to focus when switching from one project to another, we started to assign specific projects to the same pool of people within the team.
Additionally, having multiple projects in 1 sprint makes it hard to create (and meet) the sprint goals, since Enterprise projects almost always have the highest prio.
Impediments? Ehhhh… not sure…
It was impossible for the team to answer the question in the Daily Stand-up, “Are there any impediments”. For the Scrum Master it basically turned into a day-job to track progress and try to spot impediments, since the team members were neither a 100% aware of the progress of the rest of the team or of the amount of open tickets.
The burndown chart had somehow become useless. We still haven’t figured out why exactly, but it had something to do with too many issues in progress and starting new ones without finishing others first. Or not even being able to start every ticket, since we had spread our knowledge between 4 different projects. My best guess is that it came down to planning, which was impossible to do with that many issues on the board.
Sprint demos became internal knowledge sharing sessions
The sprint demo (or review) should be held for the Project Owner and stakeholders to demonstrate the (potentially) shippable product. But with our team size the meetings turned into knowledge sharing sessions where we showed each other the work we’d done and the solution we picked. Some of the solutions were even presented and discussed for the first time!! This is of course not the way sprint demos should work.
One Front-end developer vs. six Back-end developers
While we kept adding more developers, we hadn’t increased front-end capacity. This looks like a pretty obvious oversight, but since we work with style guides back-end developers can do a lot of the front-end themselves. In the end however, especially when the Enterprise projects started coming in, it was to hard to plan a sprint with a healthy balance between front-end and back-end work.
How we re-structured the new Scrum teams
Since not every discipline was represented twice, we had to add some more people to be able to make the split:
- 1 Designer
- 1 Front-end Developer
- 1 part-time Developer (who would be handling support)
In order to regain our focus, we decided to split the team up on a project basis:
- Team Shipsters – Distribution and getopensocial.com (and later on SaaS)
- Team ECI – Enterprise projects
While Team ECI works on our Enterprise projects, the teams still have to collaborate, this way ECI contributes a lot of these features back to the distribution. This has given us a huge benefit: the distribution is still a product of both teams, meaning it benefits from knowledge and input from both teams and resulting in a higher quality end-product.
I guess when you read about our problems, it’s pretty clear that the team was too big. We worked with this big team for 4-5 sprints before we decided to split it up. We would have probably split the team up sooner if we didn’t need additional time to add more disciplines to be able to facilitate a healthy split.
So when does a Scrum team become to big?
“The moment you start creating sub-groups within your sprint/ Scrum team, your team is too big”
But when is a Scrum team too small?
If the team is too big, you will run into several problems. But what happens when your team is too small? What would be the smallest acceptable team size?
In my opinion you can’t really talk about a Scrum team if the people are all working on their own little islands. The team should at least work together on (preferably all) stories. Ideally, a healthy Scrum team will also be able to handle setbacks such as illness and holidays, so I would always aim to have every discipline represented twice in one team.
Of course, I don’t want to preach that this is a must. There’s never just one answer to these types of question, there are a lot of dependencies per project and organisation which can give you different insights and needs.
What’s your ideal Scrum size? How did you first notice your team was either too big or too small? And how did you resolve this? We would love to hear from you in the comments. 🙂