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?

3 Answers 3


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.

  • 2
    +1, because I think the issue of avoiding excessive entanglement is often misunderstood. Product development without independently-deliverable increments is like playing Jenga.
    – Todd A. Jacobs
    Commented Oct 30, 2019 at 13:57

Iterative and Incremental Work Can Have Prerequisites

In the typical agile development model, stories build on one another. In this case, "independent" doesn't mean it has no relationship whatsoever to other user stories. In the context of INVEST, it simply means the story can be worked on or tested separately from other product backlog items (PBIs) currently in scope for an iteration.

Said another way, the goal is to have work items that can be completed within a single iteration. In that light, "independent" is more about the ability to deliver an increment of work within a given time box or cycle than about independence from the larger system. If your stories (in whatever format) are sufficiently small and testable, making them independent is often more a matter of perspective than engineering.

Use Enabling Stories

Using your examples largely as-is, there is a prerequisite backlog item (SAFe calls this "architectural runway" or an "enabler") to create and/or populate a database. For example:

As a database administrator,
I want to hold transactions in the "fubar" table
so that users can view, export, and filter their transactions.

With such a story delivered in a previous iteration, building the CRUD operations and other GUI elements to deliver the other three stories could be implemented independently of one another.

Use Vertical Slicing

Another way to look at the problem you're describing is that you're currently using user stories as specifications and tasks rather than as placeholders for feature collaboration. Arguably, you could rewrite your stories to deliver vertical slices of value and leave the implementation details to task breakdowns on your Sprint Backlog (or similar agile artifact). Consider:

  • Product Backlog

    As a Wholesale Widget Factor,
    I want to be able to review, export, and filter transactions
    so I can reconcile my widget accounts each month.

  • Sprint Backlog

    As Bob in Widgets 'R Us, Inc. accounting
    I want to see purchase transactions for the month in my history tab
    so I can calculate the cost of goods sold.

    As Alice from the Widgets 'R Us, Inc. budget office,
    I want to export monthly and yearly transaction reports
    so I can include them in the appropriate appendices in our annual budget.

The point here is that the feature on the Product Backlog and the implementation tasks/stories on the Sprint Backlog can be at different levels of granularity. As written (because stories are negotiable, and can be adjusted by the Product Owner with input from the team) the PBI may not be fully complete until all stories that stem from it are complete, but decomposing the PBI into smaller slices allows each piece of the feature to be delivered independently. This allows the team to provide potentially-shippable increments each Sprint even if the larger epic or theme isn't complete.

In this case, perhaps the team thinks that the PBI doesn't need to be decomposed into smaller stories. In that case, the PBI represents a vertical slice that will have dependent tasks related to the database, the GUI, and other moving parts of the system. So long as the vertical slice can be "done" or "not done" within a single iteration, it's up to the agile team to determine whether task-level breakdowns are necessary.

In a test-first development environment where the testable aspect of INVEST is in play, the need to define extremely granular stories often goes away because the Definition of Done (DoD) and the built-in tests provide more detailed guidance than a user story ever can. So long as the work increment meets the DoD and passes the predefined tests, the increment of work can be considered "done," with further refinements to be made in future iterations.

Use an Alternative PBI Format

Nothing in Scrum or Kanban mandates the Connextra user story format. The format and contents of the Product Backlog are up to the team to define, with the Product Owner as the arbiter because they own the artifact. If the user story format is a poor fit for your product, or for a particular backlog item, you're free to do something else.

User stories are only useful when they are used as conversation/collaboration placeholders. They are not specifications! The person in a user story should be a persona that is useful in providing context for the feature, and is ideally a real person who can weigh in on test cases or implementation details that are deliberately excluded from the typical user story format.

If all your stories start with "As a user" or "As a Product Owner" then either the team hasn't done enough to define useful personas, or the backlog is really being filled with overly-constrained specifications that aren't being negotiated with the people who will consume the feature. Don't do that!

Other types of backlog items may express your needs better. For example, see:

By way of example, some of your current stories could benefit from job-orientation as follows:

When I click on the "History" tab of the web UI,
I want to see an export button on the page
so that I can download a CSV file containing my transactions.

Another related story type is the test-driven story. If you're familiar with Cucumber, your team could write all its stories in Gherkin so that testability is baked in from the very beginning. For example:

Given that I'm on the "History" tab,
When I click on the "export" button
Then my browser should download a ".csv" file.

In short, the commonly-used Connextra user story format is useful insofar as it provides context and a contact point for collaboration. When the format stops being useful, or is a poor fit for your development process, inspect-and-adapt as a team until you find a more suitable way to express small, testable increments of value that can each be completed within a single iteration.

  • The thing is, in most large project delivery companies, you are never truly agile (you have a fixed scope, fixed deadline and fixed cost) but you borrow some principles, like working iteravitely, incrementally etc. So often, US are really specifications, or rather features to be delivered. And there is nothing wrong with that as long as your team delivers stories in sprints, even though there is no real PO. To be honest, true agile hardly works with real projects and big customers, unless you are in their R&D departments, which was an amazing experience for me. But not in project delivery.
    – John V
    Commented Oct 30, 2019 at 15:38
  • My point was that in such an environment, user stories are not really a place for conversation or collaboration because the overall scope is already signed off and usually only minor clarification are required.
    – John V
    Commented Oct 30, 2019 at 15:41
  • 1
    @JohnV If you fix all aspects of your project, then you aren’t being in any way “agile.” You aren’t even following traditional project management best practices. If you make scope, time, and budget equally inflexible, then the project has zero slack and is much more likely to fail. Believing otherwise is one of the main reasons why 68% of projects fail; successful project management requires at least one flexible constraint to accommodate real-world variance from an idealized plan.
    – Todd A. Jacobs
    Commented Nov 3, 2019 at 15:07

Your list of stories is perfect as written, John! The methods we now call "Agile" share in common the idea of iterative development, per William Rouse's seminal article on managing software projects (1970). They assume you will create a basic functionality, then add functionality on top of it.

Per Bogdan's excellent point, most tools I've used have a functionality for identifying serial dependencies. (My practice is to treat a preceding story as a blocker or impediment to the next story in sequence, preventing the latter from getting pulled into a sprint until the predecessor is done.) From my readings, the point to the "independent" in INVEST is that based on what has already been done, you can complete the story without completing another one at the same time (in parallel).

To your comment: In Scrum there is no practical difference between incremental and iterative. Per the Scrum Guide, you develop increments within an iterative cycle. See for example https://agility.im/frequent-agile-question/difference-incremental-iterative-development/.

  • Thanks, although it sounds more like incremental development. But on the other hand, you cannot really have increments if you do not iterate through the series of steps.
    – John V
    Commented Nov 1, 2019 at 13:49

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.