Ordering a Product Backlog to Minimize Development Team Dependencies

One of the criticisms leveled at Scrum is that it's only good for small development efforts of up to nine people or so, and defies attempts to scale it. This is despite the co-option of its vocabulary across large agile initiatives including enterprise transformations. It seems that "Scrum Masters," “Sprints," and "Daily Scrums" are everywhere, even if they are sometimes poorly understood and implemented, and even though the Scrum Guide makes little mention of how Scrum ought to be applied in anything beyond a single team context. We should not be too surprised at the ubiquity of these terms of reference, however. Scrum is demonstrably useful at a field level where teams are expected to provide value through iterative and incremental release. In Scrum, empiricism is favoured over promissory notes, the only satisfactory evidence of progress being the actual delivery of working product. That’s what counts...regardless of the scale of an undertaking.Yet it is unquestionably true that the greater the scale of an organization, the harder it is to apply Scrum. It’s common for agile practitioners to become bloodied and bitter by the experience of trying to harpoon a corporate behemoth with nothing more than the Scrum Guide at hand. Not everyone is quick to get on board and find new, scaled ways of working that support these techniques. Project managers are unimpressed by Scrum practices that appear constrained to single teams and small-scale releases. Moreover, they can have vested interests in existing stage-gated schemes where the release of value is planned, deferred and batched into years' worth of work, and for which they control huge budgets in line with traditional company expectations and established cultural practices. As if we were on the quest for Moby Dick, we may hope, at best, to remain somehow detached in these one-sided battles against an age-old leviathan, and avoid being consumed by gargantuan and timeless forces that lie beyond our control. Call me Ishmael.

Scaling Frameworks

A slew of different frameworks have appeared - or been extended - in an attempt to resolve this concern. For example, the Scaled Agile Framework has achieved considerable mindshare since its introduction in 2011, although it has received at least as much criticism for allegedly undermining some of the very principles that Scrum describes. DSDM, while arguably struggling to gain much mindshare at all in its twenty year history, has been mapped to Scrum. Most recently Scrum.org has introduced a new framework to span the scaling chasm that Scrum has left unbridged for so long. The essential component of "Scaled Professional Scrum" is the "Nexus," a collaborative team structure that is squarely focused on integrated product delivery each and every Sprint. It is a rigorous and uncompromising quality that both echoes and complements its long-serving Scrum stablemate.

The Relevance of Product Backlogs to Scaling, and an Important Concern

One of the characteristics of working at scale is that multiple teams are involved in the delivery of a product or service. In Scrum, this means that instead of having just one Development Team collaborating with a Product Owner, the efforts of several such teams are required in order to facilitate release in a timely manner. Put simply, the scope of work is larger than any one team can handle. Several teams will have to draw work from the same Product Backlog, and co-ordinate their activities so an end-of-sprint increment can be delivered, and which is fit for potential release. This in turn implies that clear product boundaries can be articulated, and that suitable owners can be found for each concomitant programme of work. Clearly much depends on how the respective Product Backlogs are structured and managed. All scaling frameworks recognise the significance of this principle.

For example, in Scaled Professional Scrum, it is asserted that "a well-ordered Product Backlog can minimize and often eliminate Development Team members working on multiple Scrum Teams during a Sprint." While this is indeed true, the statement seems to imply that this decoupling of Development Teams ought to be a consideration when organizing Product Backlogs.

Is this reasonable though, when agile teams are expected to self-organize in a timely manner, according to the work at hand? How can it be a reasonable thing for a Product Owner to anticipate and take into account team dependencies when ordering a Product Backlog? In Scrum a Development Team should take care to only action work that has been negotiated into their Sprint. They should not be performing work that remains on the Product Backlog and which they have not yet agreed to do at all. By that reasoning, a PO is simply not in a position to optimize the value of work being done by changing Product Backlog order.

The way Development Teams self-organize to deliver increments of value is entirely up to them, and is not something for Product Owners to decide. However, PO's should take into account anything and everything that can affect the release of product value...including any *advice* given to them by Development Teams. This advice may well be shaped by constraints such as the team's ability to self-organize and deliver value with the resources they currently have at their disposal.

A Product Owner can therefore consider implementation dependencies before the associated backlog items make it into Sprint Planning, but only on the basis of advice provided by the Development Team. In other words, the PO cannot order the Product Backlog in an attempt to control how Development Teams will organize themselves. It is however reasonable for teams to explain the likely impact that a certain backlog order may have on their ability to deliver future increments, and for the PO to reprioritize after considering this information along with other factors such as business value and estimated size. This collaboration may occur during backlog refinement and be improved further in Sprint Retrospectives.

Conclusion

Scaling matters are not clearly addressed in Scrum, and alternative frameworks have been proposed which share one thing in common. It is generally recognized that, in a scaled Scrum effort, the work of multiple teams must be integrated into a potentially releasable product increment.

This has implications for the Product Backlog, in so far as multiple teams can be expected to draw items from it and provide an integrated release every Sprint. If the backlog is organised without reference to team dependencies however, then these teams may find that the integration points are too complex, and that their work is too tightly coupled for it to progress without impediment. While a Product Owner should not seek to control team structure by organizing the backlog, he or she nonetheless ought to co-operate with the teams so that the risks of excessive coupling are highlighted ahead of time, and can be collaboratively managed and mitigated.