I was trying to follow the INVEST approach for our stories but frankly, the “Independent on each other” does not really makes sense. Quite often stories are building functionality upon what has been already done. For example, we have a story “As a user, I want to configure my access code” and another one “As a user, I want to activate my account”. The thing is, without configuring the access code, users cannot activate their account. Both features are independent from business perspective, you can have only your access code configured so merging them does not makes sense. However, then there is the dependency…

  • A user story should capture the goal or reason behind something; it's some piece of work that will provide a business value once implemented. Maybe (some/many) of your stories are actually tasks rather than stories. E.g., a user's end goal isn't to configure access codes; arguably, it isn't even to activate an account. Those are application-specific steps towards the end goal, but none of that is a business value in itself; the relevant thing for the business is that a sort of (virtual) space is made available to this user, and that this space is protected form unwanted access. – Filip Milovanović Jul 9 at 12:47
  • The utility of this kind of reasoning is probably not obvious on this particular example (as creating/activating an account is a common thing across domains and applications), but it will become more apparent when applied to domain-specific things, because if you capture the "why", chances are you'll avoid implementing features that superficially do what was specified, but don't actually address the underlying reason for the request (and are therefore likely useless to the users). – Filip Milovanović Jul 9 at 12:47

You should not take the INVEST principles as black and white. Especially the "Independent from each other" cannot be true for all the stories and certainly not without breaking the other principles.

User stories should be independent from each other, because dependencies can lead to problems and delays, but not all dependencies are equally bad.

The least problematic dependency is when a user story builds upon functionality that has already been delivered. For this kind of dependency, you should have some process in place (like regression testing) to ensure that the new story does not (accidentally) break the existing functionality, but otherwise it is not a problem and usually unavoidable.

If there is a dependency between two (or more) user stories that still need to be implemented, then this dependency must be identified so that it can be taken into account when estimating and planning the stories.
For example, an estimate for story A can be given under the assumption that story B is completed before it. If then the priority of the stories shifts, a trigger can be given that they need to be re-estimated.
For planning, it is best to avoid planning two dependent stories in the same iteration (or so close together that they would normally be worked n in parrallel), because planning becomes that much harder if you need to take into account that one story can't start until another one has completed.
This kind of dependency is bad when it happens at business level, because then the Product Owner can not shift priorities between the stories. If the dependency is on a technical level it is typically less of a problem, but it can affect the priority setting possibilities or the estimates of the work (because some technical work has to be shifted between stories).

The worst kind of dependency is a mutual dependency. These dependencies must always be resolved, because it effectively means that the involved stories must be worked on together as if it were one story.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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