Making backlog items independent - how that can be achieved?



  • Many sources and agile coaches repeat this INVEST mantra, when I stands for "Independent", i.e. defining stories that can be implemented in any order. While it sounds reasonable, I do not believe it can be truly followed in the practice, because most of the time, features are extended or combined, and therefore certain stories logically must go first. For example:

    1. As a user, I want to see my transactions displayed in a table...
    2. As a user, I want to export transactions that I selected in the table...
    3. As a user, I want to have [some] filters in my transaction table..

    Clearly, story 1 has to be implemented first, as the others are adding more value but story 1 has the value itself. So how can this Independent principle be really followed?



  • You cannot totally eliminate dependencies. Some story will depend on another, some feature will need another feature to be built first, some new feature will be desired only after you see and interact with some already built feature, etc. That's just the nature of things.

    So the "Independent" in INVEST isn't about eliminating dependencies, it is about minimizing dependencies.

    Dependencies are bad because they introduce issues with prioritization of the user stories, with planning, with estimations, maybe technical challenges, work becomes ineficient, etc. So you should have them as independent as possible. Sometimes this means combining a few user stories together (if they are small enough to fit in a sprint) or finding another way to organize the functionality (i.e. another way to split the functionality in stories).

    For example, you might have just one user story:

    1. As a user, I want to see, filter and export my list of transactions

    Or you might create two out of the three:

    1. As a user, I want to filter and show my transactions ("All" is just another filter in this context)
    2. As a user, I want to export transactions that I select

    But of course, you need to be pragmatic: you don't want to spend all of your time trying to find the perfect way to write user stories. If everyone is happy with how user stories are written and you can work on them without difficulties, then it's fine to leave the stories like that. Again, it's about minimizing dependencies, not eliminating them completely.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2