Article summary
Agile backlogs should be oriented to a client first, team second, and product last. At Atomic, our teams range in size from two to eight developers. Teams larger than eight generate too much communication overhead and require too much effort to manage the backlog.
It can be tempting to align a backlog to individual products, divvying up developers into multiple teams. Say, for example you have two products, A and B, each requiring two developers. While it may feel more efficient to assign one team for each product, this perceived efficiency doesn’t relate proportionally to the overall cost of each product.
Combining the two teams into one team of four developers with a single team backlog may not feel more efficient in the short term. However, in practice, it is both more efficient and more effective in the long term.
A Few Scenarios
Say product A and B are developed by a team of four with a single product owner balancing the team’s focus between the two. All four developers are exposed to each product’s code base and domain, and both products are released around the same time.
Now, things could go a few different directions based on the success or market demand for both products.
- If they both simply need small feature enhancements and third-tier support, you could scale down to a team of one or two developers with no change to your team or backlog process.
- Say one of the products spikes in usage due to a huge market success. You could shift the focus of the team of four developers to focus on enhancing and scaling the successful product while still having leftover capacity to support the less needy product.
- If both products take off and are in need of more enhancements and investment to scale, you could add a couple of developers to the existing team and dedicate more time from the product owner to manage the growing backlog.
The reduced ramp-in cost of new developers results in a more efficient project in the long term. A larger pool of developers is capable of supporting either product. This provides twice the support flexibility and more options to ramp capacity up or down without incurring ramp-in.
The overall effort is more effective due to the reduced effort to shut down, spin up, or partially allocate a team/backlog/product owner combination.
Having a team of Atomic developers who are good at switching between tech environments and quickly ramping into new ones allows us to realize the benefits of team-focused backlogs. I’ve never experienced a good reason to split a team’s backlog to focus on tech layers (e.g., front-end/back-end) or products when optimizing for the most efficient and effective agile process.