Skip to main content

Team composition in horizontally sliced stories.

Last post 05:28 pm June 12, 2023 by Nicholas Gabrichidze
5 replies
09:12 am June 12, 2023

Hello Members, Pls advise on below scenario - 

We have 14 member scrum team with 5 specialised in Backend dev, 5 specialised in front end and 4 QAs (other than PO, SM, Arch.). Since we are slicing the stories FE & BE wise considering challenges in estimation, currently we are in 3rd sprint working as one team. Now to make the events more effective, we are contemplating dividing this team into 2. What would you advise - CASE 1 - Separate teams for BE and FE (the FE team is responsible for integration with Backend within same sprint), OR CASE 2 - each team to have BE and FE combined members? In both the cases, we might have to keep QA team members common as they would be testing entire product and each module is interlinked.  One con of CASE 1 - Grooming will be repetitive with both teams but Pros - They will have flexibility in assigning work/swapping some work anytime. PLS ADVISE.


11:26 am June 12, 2023

Scrum promotes having cross-functional teams, which are capable of producing the Done Increment without outside help.  That means you need all skills in each team.

Having cross-functional teams will not remove the dependencies. Features may depend on themselves or there might be some dependencies within the components between the teams (e.g. both teams working on the same FE code etc).

Therefore you need to:

- integrate the work of both teams frequently and make sure any integration problems are resolved promptly 

- invest more effort in Backlog refinement to discover the dependencies early and address them by proper backlog ordering 

 


02:34 pm June 12, 2023

The concept of Scrum is built around a Product.  During Sprints, valuable increments of that Product are created.  It appears that your organization has defined that a front-end and a back-end that work together to create that Product.  

In my opinion, if you were to separate all front-end into one team and back-end into another, you would not be creating valuable increments of the Product in each Sprint.  You would be creating part of a valuable increment in each team's Sprints.  So, I would suggest that this is not even an option.

Your second option has merit but since you state that there would be dependencies across the teams, that could lead to some frustration and impediments that would prohibit the team from being successful.  

You do have a third option.  You said that you were going to split the teams to make the events more effective.  Is that the only option?  If the team is being successful in delivering valuable increments in every Sprint, is there something else that can be done t "make events more effective"?  Is team size the only thing that is making them ineffective?  Before I considered splitting the team, I would delve into this a bit more.  If you split the teams, you will most likely put them into a state of chaos (search for the stages of team formation) as they learn how to operate separately and it could take them some time to get back to the productivity levels that they are at now. 


03:05 pm June 12, 2023

In general never step back from experimenting just because things can get worse. This is Agile thinking, where Scrum makes part.

In general it is never bad idea to split 14 man team in smaller teams, considering that Scrum is shaped for teams smaller then 10. If you care about dependencies even 3 teams with Nexus can be considered. But it is up to you to decide.

If you split the teams better to tray letting them self organize under you guidence, instead of rigidly splitting them based on component knowledge.

As for for back end vs front end obstacles Dev Ops are  interesting thing to consider; no silver bullet of course.


04:58 pm June 12, 2023

How would people choose to self-organize into teams, so their integration dependencies each Sprint would be minimized? 


05:28 pm June 12, 2023

How would people choose to self-organize into teams, so their integration dependencies each Sprint would be minimized? 

I would start with asking everyone involved this question a  key for the next steps 


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.