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.
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.
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.
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.
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.