Dependencies First*

... your Product Backlog meets the Definition of Ready, and you have started into the Production Episode. The team is Swarming, managing the delivery of the Sprint Backlog Items for one Product Backlog Item at a time. However, there are dependencies between some of these work items.

✥       ✥       ✥ 

If critical dependencies remain halfway through the Sprint and the team is still discovering more, you risk failing the Sprint.

Significant risks can come from dependencies between Product Backlog Items, and the separate but related dependencies between the corresponding Sprint Backlog Items. Emergent requirements or unforeseen events may force the team to change the ordering of its work items. For example, a team may have to wait for a deliverable from a vendor or wait for promised, but late, lab resources to become available. Or a critical-path Product Backlog Item may become re-ordered to be later in the Sprint, when the team discovers that it has a dependency on other Sprint work. When the team otherwise defers work, it is the interest of overall progress (Someone Always Makes Progress).

You want to make sure that the team has flexibility in its work ordering, yet too much churn in the work plan creates uncertainty and raises the risk of not delivering what stakeholders expect. You want to line up work to avoid doing setup and administrative tasks twice, but it’s hard to foresee all of this at the beginning of the Sprint. Foreseen dependencies become clearer as the Sprint progresses and new ones arise, and new knowledge leads the team to re-order the work plan at each Daily Scrum. However, leaving the dependencies until the “last responsible moment” leads to inefficiencies in rework, balking, and blocking: You often don’t know when the “last responsible moment” will arrive until it has passed. [1]


Make sure that all known dependencies are under control by mid-Sprint.

You want to force emergent items to arise as early in the Sprint as possible. You do this by first tackling the most difficult issues and going into the work where dependencies are most likely to arise. This suggests a risk management strategy based on handling the most difficult tasks first. Move mutually dependent Sprint Backlog Items to the top of the Sprint work plan while still maintaining their grouping into Product Backlog Items (Swarming).

The Scrum Team can make a rough cut at properly ordering PBIs as they work towards a Refined Product Backlog before the Production Episode. However, the Development Team does the bulk of this analysis and re-ordering during the Daily Scrums in the first half of the Sprint — a Developer-Ordered Work Plan.

Occasionally this strategy won’t work and dependencies are not under control. Invoke Emergency Procedure: abort the Sprint, stop, re-plan, and start up the Sprint anew with newfound direction. Another alternative is to revert to the Sprint Goal.

✥       ✥       ✥ 

Properly lining up dependencies raises the chances of meeting the Production Episode delivery targets.

Using 5S (Seiri, Seiton, Seiso, Seiketsu, Shutsuke: Sort, Set in Order, Shine, Standardize, and Sustain) [2] techniques to scrub the Sprint Backlog is one way to drill down to the latent dependencies. Because 5S can be time consuming, the team should use it only when latent dependencies pose potentially high risk.

Jeff Sutherland relates a case study from OpenReview that they needed to remove dependencies by mid-Sprint; if they didn’t, they pulled out the Product Backlog Item. This pattern makes the problem visible with abnormal Sprint termination, rather than abrogating the team’s commitment by small cuts.

See also Emergency Procedure.

[1] Glenn Ballard. “Positive versus Negative Variation in Design.” In Proceedings of the 8th Annual Conference on the International Group for Lean Construction (IGLC-8), Brighton, UK, 2000.

[2] Jeffrey Liker and David Meier. The Toyota Way Fieldbook, A practical guide for implementing Toyota’s 4P’s. New York: McGraw-Hill Education, 2006, p. 64.

Picture from: (under CC0 license)