2 Teams, 2 Products, 2 mixed Backlogs..
Hi everyone
We have the following situation here:
- We have an existing product, that we are still supporting and developing little new features for existing customers. Parallel to this, we are developing another new product.
- We have a Scrum-Team here in Switzerland and an offshore Scrum-Team in Vietnam, both with PO, SM, Developers.
- Both Teams have their own product backlog in TFS and working in their own sprint (One team from wednesday to wednesday in 2 week sprints, the other team from friday to friday in 2 week sprints too). According to this, each team has it's own sprint backlog.
The problem is, that both teams are working for both products and our PO's are creating the user stories in their own product backlog. That means, we have two product backlogs but with mixed items in it for different products. Like this, it's more or less a 'Team Backlog' instead of a 'Product Backlog' at the moment. This makes it realy hard to have the overview over the products and their user stories.
Now I am trying to clean up the situation and want to ask you for some advice, how do I proceed as good as possible in this case?
- Make both productbacklogs productbacklog again => just stories for 'this' product and not mixed with stories from other products.
- But how should the teams working together? Should the developers 'change' the team for a sprint? Or should I just plan the capacity for the estimated time a developer needs for a specific story in one sprint?
What would you do in this situation?
Thank you in advance for your advice!
Cheers
Immanuel
Each product must have its own Product Backlog.
Presumably there must be some reason why your teams cannot (or should not) work on one product each. Assuming that is the case, both teams can work on both Product Backlogs if necessary, but no team should work on more than one product per Sprint. Any given team can work from two Product Backlogs in alternate sprints. The sprints would have to be short enough to ensure that a potentially shippable increment is available at intervals no longer than one month.
For a team working on two products, and therefore two Product Backlogs, this would mean having sprints of no longer than 2 weeks. One sprint they would work on one product and during the next sprint they would work on the other. There's nothing to stop both of your teams from having this arrangement, but each Product Owner would have to co-ordinate the work of two teams, and the teams themselves would have to co-ordinate their release dependencies for each product.
That's complicated, and it brings scaling issues that may be unnecessary at this stage. I'd therefore try hard to keep it simple, and get each development team working on one product backlog and dealing with only one product owner.
Thanks for your answer, Ian!
"I'd therefore try hard to keep it simple, and get each development team working on one product backlog and dealing with only one product owner."
- that's the way I would love to have it..
"Assuming that is the case, both teams can work on both Product Backlogs if necessary, but no team should work on more than one product per Sprint. Any given team can work from two Product Backlogs in alternate sprints. The sprints would have to be short enough to ensure that a potentially shippable increment is available at intervals no longer than one month."
- I think you are right, the best and simplest way is to 'exchange' developers only for full sprints and not allow them to work on two sprints for different products at the same time. I think to keep this as simple as possible, I should 'synchronize' the sprint days, this would simplify an exchange from people between the teams.
Thanks again and I still appreciate further advice :)
Cheers
Immanuel
Hi
I've just read the Nexus Guide. It seems that implementing the Nexus Framework in our organization could be a big benefit. Is there an experienced Nexus SM who could confirm that?
Cheers
Immanuel
What is the reason behind such approach - having two Scrum Teams working on two products? Is it knowledge based? Is it requirements? Changing market demand?
Sounds like type of multitasking for both teams. How POs are deciding what kind of features to implement if particular product?
According to Nexus - it's framework for delivery in scaled conditions. I do not see direct connection between applying nexus and difficulty with deciding which product when to deliver.