Skip to main content

Splitting scrum team into smaller teams

Last post 05:05 pm September 27, 2021 by Gonzalo de Diego Ramos
5 replies
11:24 am September 22, 2021

Hello, we have currently decided to split our scrum team into 2 or 3 smaller scrum teams. We will all be working with one product backlog since we have one product goal.

How do you suggest to deal with scrum events such as planning, sprint reviews and retrospectives, should they be held separately for each team or together?

Also any tips or advice would be great, if you are working with similar methods.

Thank you.


06:14 pm September 22, 2021

How many total people do you have? Are the people able to self-organize into smaller teams?

Once you reach 3 teams, you can begin to look at more structured approaches for scaling. Some options include Nexus and LeSS. However, you can also look at applying dynamic reteaming approaches, the idea of fluid Scrum Teams, or FAST Agile. Whether you go with stable or dynamic teams depends on the organizational context, but you have choices. If you do go with more dynamic teams, some of the LeSS structures may still be useful, but you'd have to make changes for dynamic teams instead of the stable teams that LeSS defines.


06:41 pm September 22, 2021

How do you suggest to deal with scrum events such as planning, sprint reviews and retrospectives, should they be held separately for each team or together?

Try to keep things separate as far as possible, for simplicity. It's best if each team can inspect and adapt locally, with minimal integration dependencies.

Have you taken care to minimize such dependencies? Can each team provide a Done feature-complete increment under its own steam?


07:12 pm September 22, 2021

This is my favorite principle from the manifesto for agile software development.

Simplicity--the art of maximizing the amount

of work not done--is essential.

As @Ian Mitchell suggests keep it as simple for the teams as possible.  I would also suggest keeping everything separate unless there is a compelling reason for something to be combined.  Then I'd go down the path suggested by @Thomas Owens.  But I would not start with those complexities.  Start simple, inspect and adapt as necessary.

A side note.  If you are splitting one team to multiples but not adding extra Scrum Masters or Product Owners, you will be increasing the work for those two roles. It will become more difficult for them to do any type of extra work.  The Developers may have to participate more by taking on some of the activities that are currently done by the Scrum Master and Product Owner.  Also expect some reduction in the Developers ability to deliver value as they will have to learn new things and adapt their working behaviors.


10:31 am September 23, 2021

Splitting the team into multiple Scrum teams and combining the Scrum events may not fulfil the expectation.

combining events may look like minimising the meeting time from the Product Owner and Scrum Master perspective But for developers, they may spend more time than what was suggested in Scrum guide for each event

Probably, Demos part of Sprint review could be one event to merge so all the teams get to know the increments in their product as a whole. Speaking about integration then it should be more a Scaled approaches than just Scrum.


11:33 am September 27, 2021

Is the splitting that your team has made the one that best reduces dependencies and integration issues?

As there are less problems with dependencies and integration, the need for coordination will get reduced. The system will be simpler and the necessity to establish common events will decrease.

 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.