Product Backlog ordering
Hello, All,
I have a question related to the product backlog. So I bought mplaza course and in the guide there is sentence: The product backlog is the only one no matter how many teams working on the project. So as we all know the top of tickets in the product backlog are with the highest priority. But lets assume that we have development team which contains only developers who resolve programming tasks related to product and we have second team which contains people who are aware of deployment of product. Completely different team with different tasks. They should use same product backlog and development team tasks are on top of product backlog and deployment team tasks are below devs tasks.
So the question is how deployment team know which of their tasks are with the highest priority?
Thanks,
Dobromir Simeonov.
Each Scrum Team should be able to complete any item according to the Definition of Done (production ready).
It doesn't seem like your teams are configured this way. Specialization around individuals/teams is against Scrum/Agile.
Just curious, what issues might you experience if those two teams were split in a manner where the skills and expertise were evenly distributed? What benefits might there be?
So the question is how deployment team know which of their tasks are with the highest priority?
Wouldn't it be better to ask how teams ought to be restructured, so that each can produce feature-complete work which is continually integrated into the product?
I think the question and the description point at two different problems.
1. How to prioritize work for large product where multiple teams are working together? In this case, multiple teams will have to share the same product backlog. Example: if the product is an e-commerce website, one team might focus on payments while other on catalogs.
For answer to this, scaling frameworks such as Nexus might be better to determine the right approach for you.
2. How to organize multiple teams that are both independent and self-sufficient to deliver value? Dividing teams by skills such as programming vs. testing vs. operations/deployments is going to encourage more silo'd waterfall-ish work while losing out on all the benefits of being Agile.
You might want to re-look at the value chain on how a business outcome is delivered and organize around that.