1. One single backlog
Just to be clear from the outset, this blog is about when you’re dealing with more than one Scrum team. Let’s assume you’ve decided what product you are going to deliver (in an agile way), you are using Scrum as your empirical process framework and you now know you need to add to the single Scrum team that has forged the way ahead on the product.
Pretty soon you’ll get to the question of, ‘well, if we have more than one team won’t we need more than one backlog’? Wouldn’t it be sensible to think that each team will have one backlog and a product owner each?
The short answer is ‘no’. Let’s explore why.
Firstly, when scaling in a Scrum environment, the question of ‘how many backlogs?’ should be addressed from the very start – it will save you a lot of pain. Trust me.
There are many reasons why you might think having a single backlog for each team is a good thing. These may include:
- Each team will have its own dynamic and should be empowered to deliver as independently as possible.
- Each team needs to size and commit to things that only they are on the hook for getting to Done, as agreed with the PO.
All of these examples are relevant and very valid, particularly in one-team Scrum. However, and this is the key thing, having more than one team introduces more variability, complexity and inter-team dependencies. In fact, it introduces so much more complexity that you need fresh thinking to address multi-team Scrum.
Don’t just take my word for it; both Scrum organisations (Scrum Alliance and Scrum.Org) offer frameworks for dealing with Scrum at scale.
- Scrum Alliance offers LeSS (Large Scale Scrum) as it’s chosen partner for scaling, which, as part of an initial set of scaling rules, recommends one backlog for each product ‘that defines all of the work to be done on the product’[1].
- Scrum.org, with its Nexus framework advocates that ‘there is a single Product Backlog for the entire Nexus and all of its Scrum Teams’.[2]
So that’s grand – the two heavyweights of the Scrum community say you should have one backlog at scale.[3] So what? How will it help?
For me it helps on several levels.
It creates and consolidates a view that there is one product, and the items that are required to produce the product need to be prioritised within the same context for the appropriate team to build them. In the grand scheme of things this item is more valuable to the Product Owner than the next, so that is what is prioritised across the entire product (Systems Thinking in other words).
Scrum Masters may have encountered instances where some teams working on the same product with individual backlogs have prioritised lower priority product items because the backlogs are silos of functional items prioritised at the team level. That results in what Larman would call a ‘local optimisation’[4] and therefore not optimised for the system. Having one backlog for the product is a way to avoid this kind of issue.
Equally, when teams are refining backlog stories they will have a pretty good idea of which team will be picking up a given story as they get refined. If the ‘integrated increment’ (Nexus) is to be fully integrated and delivered by multiple teams, they need to understand any dependencies and co-ordinating activities that should happen during the two-week sprint. They have an opportunity to call this out in the cross-team planning session or, Planning One (LeSS) and Nexus Sprint Planning (Nexus).
Of course, having to integrate the code on a regular basis will reinforce the team dependencies and equally, Scrum Masters working across the teams will also enhance the co-ordination (at least this is how the LeSS framework does it).
Most importantly, there is a flow gain from the approach. As the teams are multi-skilled non-component based functional teams, we can reduce variability and increase flow ‘because a user story can flow to any one of several available teams.’[5]
Questions about sizing are really red herrings in this debate. It really is not the point here. The point is cross team collaboration/co-ordination, flow at scale and prioritisation of more valuable items in a scaled environment. One rule however, should be that team velocity is not compared in this approach. Furthermore you can add a short cross-team refinement session where items are sized by representatives from each of the teams, before being more fully refined by the team most likely to take the item on in the sprints.
Neither does the multiple Scrum team approach devalue the ‘empowered teams’ Scrum philosophy. There is nothing different here – they are still Scrum teams, however they now have sight of what other feature teams in the system are working on and can plan and agree inter-team product dependencies accordingly.
So, in summary, the tip for this month is have one backlog for each broad and wide product. How you plan for that also needs some adaption to single team Scrum ceremonies – but more about that next time…
