Our scrum squad consist with three teams (Back-End, Front-End, QA). Each team expertised in their own set of technological stack and of their own code bases (repositories).
I'm aware that cohesive skilled team is a key to achieve most out of scrum team. However in this particular case its not an option.
As usual, squad burns down assigned user stories inside a sprint and most of the time, Front-End team produces lot of bugs (defects) inside a sprint cycle.
Even they spend overtime, all nights, double shifts, they only can resolve 90% of the bugs within a given sprint period.
The remaining 10% is mostly the complex bugs. Even we provide few extra days or in some cases an extra week, they fails to deliver. Most of the time the only option is go back and change the already committed code base to a new development plan. Which seems like a whole new sprint.
I'm continuously seeing this issue after I joined the team as a product manager.
What does this particular team miss here? What resources I should provide them? What's the project management workflow to handle this? What would be the company's management workflow to handle this? As a product owner, should I be responsible for this unskilled team?
Edit: Added few notes to clarify few doubts on comments and original answers
Why "its not an option" to have a cohesive skilled team
- We really need to stick with sub teams for now. API is legacy, and needed lot of training and years of experience to maintain it. We are fortunate if we could find fullstack developer with knowledge of this early 2000's code-base and with modern browser UI framework. Reality we are less fortunate and really "Its not an option".
- And I'm a personal believer of a separate QA team, who are specialized in the field. Who does full day testing and who does have spare time tp break the system with loads of regression tests.
How sub teams operate as a scrum team
- Sprint planning usually happens collaboratively with all the team members. And most of the acceptance criteria comes from me and team comes up with more edge level acceptance criteria cases.
- Each user story gets assigned by one person from each team. As an example, one from UI, one from API and one from QA team.
What happens in retrospectives
- We are in a loop of pointing out the issues -> Team records it -> on next sprint, same issues -> Retrospective
Why still slavery exists in our team?
- This isn't something SM, PO or someone came up with. We strongly discourage of doing overtime, all-nighters. We do discussions, send notices to the team members. However it's something each developer or tester committing. Sometimes, even when not at office. I believe its a matter of the cycle which individual producing less quality work, then that person fear of nearing deadlines or feels guilty, and they work more to cover.
- Our scrum team consists of 9 people including me.
- Usually we have 2 weeks sprints (10 working days)
- I table a priority list of stories.
- Its the team who (exclude me) picks the stories for the sprint duration.
- Its the team who (exclude me) of scoring the stories.