Skip to main content

Split scrum teams feature based

Last post 07:30 pm December 2, 2016 by Xsdds Ejej
9 replies
03:47 pm October 23, 2016

I am heavily thinking about a topic for days now and can't come up with a solution.

I am a scrum master and we started scrum 6 weeks, so 3 sprints ago. Now our team working on the same product will be extended to 18 team member, excluding SM and PO.

We will obviously split the team, but I don't know how.

We are working on a gui with let's say 60 dialogs. Each dialog will take multiple sprints and realisticy only two to three team member can work on one dialog.
In all the meetings like daily and sprint plannings, I noticed that the dialogs are so different that one team member working on dialog a is not very interested in dialog b.

The result would be to split the teams into one base team, consisting of six team members and four teams consisting of three team members each, doing features, so a mixture of component and feature teams.

I read alot about this topic and it was always said that it should be at least four members in a team, five to six is ideal.

What do u you advice?
I feel like if I split it into three teams of six members each and working on two epics per team might not be efficient, as half the team would discuss stories, which they won't work on.

I apppreciate any input.

08:53 pm October 24, 2016

Theoretically, the dev team is to decide how to split, not to adapt a decision made for them. However, it doesn't mean nobody should guide them
I'd recommend asking the dev team questions, like "if I ask you to split the backlog items by complexity/technology/hierarchy/etc. how many groups would you define?" or "what are the dependency you see with implemention of these backlog items?"

If all the tasks are really independent from each other, I'd recommend having larger teams rather than smaller.

And, BTW, where did you read 5-6 is an ideal? Scrum guideline recommends 3-9.

P.S.: Here're a relevant topic you might like to read:

11:55 pm October 24, 2016

Regardless of how the teams are put together, they will need to collaborate on delivering an integrated release-quality increment each and every Sprint. With anything more than 2 teams a Nexus is likely to be needed to co-ordinate the associated dependencies.

So, if a Nexus was to be implemented in your situation, how would it want those integration dependencies to be resolved? How would Development Teams be assembled in order to make the integration challenge easier to manage?

04:22 pm October 25, 2016

Hi Ejej,

I understand that there is limitation on how much you can explain online and how much I can visualize. Let me explain my experience about similar situation which might help you.

If there are multiple items of similar type of technical work, try to group them in feature/epic such that there is minimum interdependence. In order to create cross functional team, check what are the skill required to complete each work item. Based on timeline available and resources in hand, you can decide how many cross functional teams can be formed. It looks like you have full stack developers who would like to finish work item completely on their own. To increase level and need of collaboration, suggest team to swarming so that when one developer is coding other will create test cases or test data. If required, use pair programming or pair review so that knowledge is available with team rather than any individual.

05:41 pm October 26, 2016

Thank you three for your input. It definitely helps. What I learned so far is that the team should try to find itself by identifying how they think is the most efficient way of finishing work. That is what we will try tomorrow. I also like the input that not every developer needs to do all tasks of one story. They kind of know that but not to the full extend.

And I will give myself and the teams more time to prepare the split to be fully prepared.

I will let you know how it developed.
Thanks again.

11:52 pm October 27, 2016

Please update with the actual outcome after your next sprint

07:53 pm December 1, 2016

Hey everyone,

I owe you an update on the transition.

We are in our second sprint after the transition. We now have one components team for base development, which is currently mainly doing bug fixes, because it is the bottleneck for the other teams. This teams consists of seven team members.

Then we have three feature teams with four members each.

The result is: overall I am happy with this current state. It worked out pretty well. The teams do work together, don't block each other and talk to each other. And today it happened that the team members started to identify issues themselves (one was taking note of the things that hold him back from his actual tasks yesterday. I was able to talk to him about those issues and worked out solutions to solve those.)

There is still one person who is blocking and tries to "argue" against all this. It it very tough to make him a real part of a team and I fear that his behaviour is slowing his team down. But at least the other members don't listen too much to him and try to push scrum instead.

So overall I feel like we are going in the right direction, although I know it would have been better to get a coach in the first place. If this big project is over, I definitely plan to do this.

09:54 am December 2, 2016

Try to find out why that person is against the new arrangement. What are his apprehensions or motivation? Ask for Scrum adoption impediments during the Sprint Retrospective meeting and how can the team or Scrum Master resolve them.

03:41 pm December 2, 2016

I recently attended a great meetup that was about working with difficult people. There were many great takeaways, but one that really stuck with me is as follows:

It is extremely rare to come across someone who just likes being a jerk. In almost every instance where someone is being combative, or difficult, or poisonous to the team, the key is to realize that their behavior is a means to an end. What is their motivation? What are they hoping to achieve through the behavior? What is their end-game?

Once you gain that insight, you're much better equipped to address that behavior (and that person) going forward.

Good luck.

07:30 pm December 2, 2016

I talked to him personally. He mainly says that he thinks "all this story writing and those meetings are a waste of time", but he immediately admitted that he does not have a better solution.

I personally feel that he does not like the changes of roles. He is still the team leader of most of the guys of the feature teams. Due to the small self organising teams, his role does not have that much of an impact anymore.
And I feel like he fears that he is not able to keep pace with all the new changes. I tried to work on this topic by helping him on specific topics. But on the other hand, I don't want to treat him like a special case who is the only one who needs assistance.

I don't feel like I can solve this on my own or at all. My hopes rely in all the other teams and team members. When he sees that 17 out of 18 have improved on productivity and quality, he might start to reevaluate his role and behaviour.

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

Please note that the first and last name from your 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. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, 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 may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.