What do I do when a User Story is dependent on another? Well, the most important thing is, to quote the Hitch Hiker’s guide to the Galaxy, “Don’t Panic!”.
I believe dependencies between User Stories are often over played. Sure there are dependencies but often these don’t require any particular management. But even more common are invented dependencies, i.e. dependencies that are more apparent than real. This means dependencies for me are a bit a of requirements smell, i.e. something to be worried about.
“I” is for Independent
A dependency between User Stories means that if US2 needs US1 then you must do US1 before US2. But dependencies are bad. The “I” in INVEST stands for Independent. So Agile teams try to reduce the dependencies between User Stories to allow them to pull User Stories into development in any order the business wants.
Having said that I agree with Mike Cohn that it is nearly impossible to remove all dependencies. However I do think most dependencies are more obvious than real. Or, put another way, they are made up.
The first one problem
Dependencies loom large when entering a new area of the product. The first User Story in a new area always comes with some technical overhead. The developers have to set up the core domain entities plus associated database tables and testing mechanisms. This takes time. So the first User Story in a new area will always take longer. It carries some weight.
For the Plan Ad Campaign epic the Create Campaign User Story looks a good candidate to do first. To carry the overhead. That means all of the other User Stories are now dependent on it. You cannot, for example, start Edit Campaign until the first one is done.
User Story Dependency – First One Problem
The natural order
There is usually an obvious, or natural, contender for the first User Story. Mike Cohn pointed this out in his post on Estimating Work Shared Between Two Backlog Items.
The dependency diagram below shows the natural order for the Plan Ad Campaign epic. It starts with the Create Campaign User Story then moves into Edit Campaign and Delete Campaign. This is “natural” because you need to create something before you can edit or delete it. And editing is probably more common than deletion. The product owner could prioritise these in any order but it will seem natural to everybody to do create, then edit then delete.
User Story Dependency – Natural Order
The good thing about the natural order is that it is obvious. And in the Agile world you don’t need to document the obvious. For example, a Gantt chart showing that Edit Campaign is dependent on Create Campaign doesn’t really tell us anything the team didn’t know already and don’t need reminding about. So I don’t bother with that.
Decoupling the natural order
Despite being obvious the natural order is not the only possible order. In fact parts of the dependency chain are really just made up. For example Delete Campaign doesn’t have to come after Edit Campaign. Once you have Create Campaign you could do either edit or delete without a problem. The Create Campaign User Story carried the weight of being the first in the Plan Ad Campaign epic so edit and delete are really both dependent on create alone. The following dependency diagram has removed some of the made up dependencies of the natural order for Plan Ad Campaign epic.
User Story Dependency – Natural Order Decoupled
Challenging the natural order
The trouble with the natural order is that it is all made up. Something can be obvious without being a fundamental truth. Putting the Create Campaign User Story first, and giving it the associated overhead, might be obvious but it isn’t a given. You could pick any User Story, for example, there might be good business or technical reasons why you would do Book Campaign first. This User Story would then carry the weight on being the first in the epic.
User Story Dependency – Natural Might Not Be Right
The common counter to this is that to Book Campaign you must have already done Create Campaign. Not true. All you need is a campaign in the database in a bookable state. That just requires a SQL insert. In contrast Create Campaign is a User Story with a user interface. To implement Create Campaign involves some UX design, front end development, back end development. To do Book Campaign you don’t need any of that, you just need a SQL insert. You have created a dependency that doesn’t exist.
Distinguishing technical dependency and business priority
Technically there is no dependency between Book Campaign and Create Campaign. One of them carries the overhead of Plan Ad Campaign but it could be either of them.
The business might see it differently. They can’t do SQL inserts so will be interested in what is available in the UI. So they’ll incline towards the natural order and prioritise Create Campaign.
But what if you can import campaigns from another system. In that situation the Product Owner may well prioritise Book Campaign and associated User Stories ahead of the normal create, update, delete ones.
That is the point really. By removing technical dependencies we give more power to the business. They get to prioritise anything they want. And it might not be obvious or natural.
Rewrite to make independent
If you have a real dependency between two User Stories, aside from the first one problem, then I suspect there is something wrong with the User Stories themselves. You should consider:
- Merging the User Stories that are dependent
- Rewriting them without the dependency. You should definitely do this if you’ve got a cycle.
This post is part of my What do I do When … ? series. Please drop me a line or add a comment if you’ve got a question you’d like answered.
Steven, very clear and helpful, thanks! Encountered this challenge of story dependencies in a sprint planning session yesterday, so your article was very timely.
But in reality, you always have a lot of groundwork to do for certain story-groups or epics. So you end up with a tree, where the stories with the most preparation stuff with databases and custom components are the heaviest that block everything else. The more complex the product is, the more the stories are interacting with each other. So even showing a small piece of information can have a huge workload behind it. How do you deal with huge backend preparation tasks that are dispersed throughout the story dependency tree?
The “lot of groundwork to do for certain story-groups or epics” you mention is exactly the “first one problem” I described in the post. You can’t avoid the first one problem. The point of my post is that you have a choice about which epic/user-story goes first and carries that extra weight. I recommend Pain driven development and deferring the “huge backend preparation tasks” as long as possible. Do the minimum necessary back end work for each epic/user-story.
But what if it is like this, that for each story you have to implement another “first one story”, when all features are built on each other? It prohibits any parallel tasks and we get back to waterfall. If you want a feature, you need a user. If you want to have a user, you need a login. If you want login, you need a start page where to login.
There is a lot of overhead for story driven development in the beginning phase of a project, so I wonder if it makes more sense to first analyse the components that are associated with several user stories, and all the dependencies that are created. Then the team could work on this very big first ticket which has a bunch of user stories in a bundle, and only start with story driven development for stories that are technically independent and can be developed in parallel.
Conceptually that degree of dependency is possible but in practice it isn’t likely to occur.
I don’t use the approach you are suggesting for a few reasons:
(1) It breaks the principle of user stories as thin vertical slices from UI to backend.
(2) it delays when valuable software is ready for use
(3) it encourages over engineering by the development team and is likely to produce a framework, whether or not you need one.
(4) it is likely to result in code that is unnecessary, e.g. you thought it was needed, was a dependency, but when you start the real user stories you discover you didn’t actually need it or it was for a low priority user story that you never quite get to = Waste
Apparent conflicting technical and business dependencies can be hassle to negotiate bit I would argue the dependencies can be simplified in this example. There is presumably one group of dependent requirements that are concerned with the content of the campaign (1) Primary: Create Campaign, Secondary: Edit & Import Campaign. And other concerned about the booking of a Campaign: (2) Primary: Book Campaign Secondary: Amend Booked Campaign. Provided the process of booking a Campaign does not need to know anything about the Content of the Campaign (1) & (2) are entirely non-dependent. As are Delete Campaign and Cancel Booked Campaign. These are all operating on an ‘whole object’ and thus do not need any information about the contents of that ‘object’ to be coded. Yes for testing it will need a kludge if Delete Campaign is developed before Create Campaign but this kind of so-called technical dependency is largely an illusory impediment to parallel development. All the teams need to agree on is the name of the ‘Campaign’ class (plus maybe some technical details about how the class is stored/realised) but for most frameworks/languages/domains this will be obvious. i.e a record in the Campaigns table.
Having said all that I don’t think there’s anything wrong with developing functionality in the natural order of the user journey: it tends to help users/testers spot issues/improvements early without unnecessary waste bing spent on ancillary functionality.