In the company I currently work on, we've noticed that sometimes, some stories are bound to each other (as in too coupled). This might be that they belong to the same overall feature, or that they're different features but there are some of them that need to be finished first in order to continue with the next ones, etc.

How do you handle this cases, without stopping the workflow of the iteration? Are we doing something wrong?

4 Answers 4


This is a great question. Theory says that user stories should be independent but I was never able to fully achieve that.

In my opinion the most important is communicate the dependency so that both team and product owner are aware of that. This will force product owner either to redefine user stories so that dependency is removed (for example by merging user stories) or to define business priority accordingly so that principal user story is implemented first.

Based on the priority and PO decision you will either implement both of them in the same sprint or the dependent one will be implemented later without any problem because the principal will be already done.

The worst case is if A is dependent on B and B is dependent on A. In such case user stories are most probably incorrectly defined and should be probably rewritten to A and B (mostly independent or with only one way dependency) and C dependent on A and B.


Plan them accordingly.

Put them in the same sprint, and since user stories are also prioritized in a sprint backlog, you won't get any problem.

Since your team participate in this, they are aware of the dependencies, so there is nothing you should be afraid of. They are adults and if you explain them about dependancies (usually they will explain that to you), things will go smoothly.

In Agile, like in Waterfall, you can do only one thing at a time. And you usually do A before B if B needs A. That's common sense.


Dependencies might be a smell that you're slicing your stories horizontally instead of vertically through the system. Development for a particular feature should involve everything from modifying the database design right through to the user interface. If you find that you're spending all of your effort on a user story in some lower level of the system structure, like, say, writing handler routines for database lookups, then you're more likely to be creating dependencies between stories. And, you're probably writing your user stories wrong.

  • 2
    So how would you handle splitting stories on a online store. Users should be able to view a list of products. They should be able to search, filter and sort the products. In my mind, each of these actions is large enough to warrant its own story. But you can implement the product sort before you have the List of products in place....
    – NSjonas
    Jul 29, 2015 at 23:42

Your best bet is to break up your ddependent user stories into smaller bits which can become as independent as possible. They you should tacke the stories which are most depended on first(like you said: the ones which need to be finished first in order to continue the others). Create something like a dependecy index: If story 3 has more depedndants than story 1 you shoud tacke story3 first.

If your dependencies are causing too many stopages it may be a good idea to stop work altogether (yes right in the middle of your current sprint) and reassess your priority user stories and tackle them first

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.