Dependency is a 4-letter Word

When I began my path as a Scrum Master I viewed our backlogs in a very linear way. Highest priority stories at the top; lower priority stories toward the bottom. Clean, but linear. Over time I learned that some of my teams’ biggest stumbles were caused by this perspective. But I should probably reword this: our biggest stumbles derived from not understanding the multi-dimensional information hidden in a backlog.

To explain this I will appeal to a backlog challenge I have seen on several of my teams. Here’s the background.

The team had a delivery deadline two sprints away. The general feature and story goals were understood, but the timing of endpoint delivery from other systems, plus a crunch on our developer capacity were fragmenting our original plans. I scheduled a team meeting at the end of Sprint 7 to dissect where we were, and what remained. Prior to that meeting I threw together my view of our backlog. Here is what I presented. The dashed line indicates dependency; the two-sided arrow points to the entity depended upon:

In this meeting I explained the several dimensions of risk inherent through this view of our Product Backlog.

First, we had only two sprints remaining – Sprints 8 and 9.

Second, we had a lot of dependencies. This was a bit of a shock to them because they had evaluated and approved the readiness of each story based on a Refinement evaluation that included the question: “Does this story have any dependencies to other stories, or from other stories?”

As you can see from the diagram, this team faced significant risks from both intra-sprint (within) dependencies, and inter-sprint (between) dependencies. Intra-sprint dependencies are true red flags. If Story-B depends on the completion of Story-A (A <--- B) within the same sprint, these must be completed sequentially. If Story-A is delayed then Story-B moves into the next sprint, stories in that next sprint may be displaced, and the team may have to struggle to find capacity to absorb this unplanned but injected Story-B. In a scenario such as this, your team’s predictability goes down the tubes.

An additional risk on the OrderValidator led the team to choose first constructing a skeleton, or thin thread, OrderValidator in Sprint 8 to prove the component design was correct, and then add the full execution of business rules in Sprint 9. But both OrderCreator and OrderUpdater ultimately depend on the full, finished OrderValidator, and this forced rework in Sprint 9 onto the OrderCreator and OrderUpdater components.

Compounding the turbulence for this team was their transition from using mock objects to simulate interfaces of external systems, to expecting interjection of live endpoints for these systems in the middle of Sprint 8.

I know this might be a little difficult to follow. My point in this is: just laying stories linearly into a backlog stack does not reveal some of these very real risks. Without analyzing external injections of components and the direction and duration of functional dependencies, you and your Product Owner will be challenged to establish a realistic Product Backlog and predictable delivery. So, dependency really is a four-letter word: RISK. But dependencies are not the only risks, of course.

To make planning even more challenging you will see at the bottom of the diagram that the team had eight developers in Sprint 7, but we lost one developer at that time. And they already knew their capacity would fall by one more developer for the second week of Sprint 9 – roughly a 25% capacity loss over three weeks. This, also, is not a project dimension found in looking at a linear Product Backlog.

You might be thinking, “This is not Scrum Master responsibility. This is analysis a Project Manager should do!”

True. But what if your assigned Project Manager does not have an adequate skillset to appreciate the technical dependencies? What if you have no Project Manager at all?

As effective Scrum Masters we must wear many hats, which requires us to have a toolbox of diverse skills. Our purpose is to guide and protect our team, not to balk and say, “that’s not my job.”

Those of you familiar with SAFe (Scaled Agile Framework) will see a similarity between my diagram above, and the Program Board in SAFe PI Planning. That is not an accident.

And it is not an accident that my teams always see diagrams like the one above because I want them to understand that if they do not embrace this nuanced view of their Product Backlog, they may find themselves thrashing in their sprints when the dependencies arise with a vengeance.

I love working with teams and executives to find effective solutions. Email me at gary@effectivescrummaster.com and let's explore how we might partner on your challenges.