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.
