Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 4 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
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 '15 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

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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