As I work on more and more agile projects and with new development teams, I find that dependency management remains one of the top concerns and hurdles to effective agile projects, even for seasoned agile teams.
In one of my previous posts, I talked about Agile Requirements Documents as a way to identify and interact with dependency teams earlier in the agile process than might be strictly “agile,” but as a way to ease the transition for interfacing teams and business partners new to agile.
Today, I want to talk about how we might manage dependencies in agile after the dependent/interfacing requirements have made it into the backlog. One mechanism that has worked for us on agile teams, to manage requirements that are dependent on more than one team to deliver, is to create linked duplicate user stories in each team’s backlog. This is easy enough with most requirements tools- just create the user story, mark it as dependent on another team (maybe in the title or with an attribute), ensure that story is duplicated in the dependency backlog and link the two stories (affected by or related are good relationships for this since they are bidirectional most of the time.)
Now, you could have issues with even this first step if your requirements management tool has multiple instances, for example; I’m not going to cover that here. Assuming you don’t have this issue, great, you now have the requirements in both backlogs; now, how do you ensure that the dependent requirements are delivered at the same/right time? If they are dependent, then there is likely a fixed date release they each must meet either for them both to work together or for one team to finish before the other for testing/integration.
This is very hard problem and one my coworker likes to call the “rocks in the river” problem. That is because we think you should treat these requirements as rocks in a river; in that the river can flow around the rocks, but the rocks are fixed in space. If you are canoeing on said agile river, you would be able to see the rocks coming and swerve around them (I know- I’m mixing metaphors here, but stay with me!).
In a backlog sense, what this means is that the dependency requirements should be fixed in the backlog to a specific sprint, iteration or due date. Other requirements could move around that dependency, but should not push it out past its sprint, iteration or due date. Getting your requirements tool to do this part is tricky, but you could manage it with some internal processes as to how you use your tool. For example, you could label all dependent stories as “Dependent” or “Rocks” or anything else to signal to the Product Owner that these should not move out of the sprint they are assigned to (and put the due date in the description or as an attribute in case sprint numbers change or get pushed). This would have to happen in both backlogs to be useful. Then, if the PO tried to add anything above the “rock,” she would know that something else might have to move out to keep the “rock” in the right sprint. Or if the dependent product owner tried to move a “rock,” he would at least have it there to see. It would be interesting to be able to put an attribute on the requirement that would lock it in the backlog systematically, but I haven’t seen any tools that do that yet. (One way this might look is below)
One of the interesting things about this approach is that you can now manage your dependencies via a dependency/shadow backlog. You could write a query or filter only for those requirements that have the signifying attribute/title and view their linked requirements to see that status of your dependencies. You can then review this in a dependency meeting or a Scrum or Scrums. This can help you answer questions such as: Product Owner B moves a “rock” out of the needed sprint. At the Scrum of Scrums, Product Owner A who needs that “rock” can view just the “rocks” and their links to see that the team B “rock” has moved and ask why. Maybe the “rock” can move on both teams, or maybe Team B needs to put the “rock” back in the original fixed date sprint.
This is not an end all, cure all to dependency management and even if you implement this, you will need someone actively curating the backlog to keep the “rocks” in the right place and properly labeled and someone looking at the “rocks” and the other teams with those same “rocks” to ensure a partnered delivery. How do you manage dependencies in agile today?
