Can stories always be independent (following the INVEST principle)?

Question

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…

Answer 1

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.