Team composition in horizontally sliced stories.
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.
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
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.
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.
How would people choose to self-organize into teams, so their integration dependencies each Sprint would be minimized?
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