Achieving independence for story items

Question

I've been reading a lot about agile, stories, and INVEST recently, and trying to apply it to my work (with a view to introducing it all more broadly within our organisation).

I can see the value of Independence (and other points) within the INVEST mnemonic, but I'm not sure how it should work in some scenarios.

As an example, I'm writing a tool from scratch at the moment. The basic intent is so that it can pull lists from a database. So of course, I can write stories like:

As a user, I would like to be able to get a list of all users from the database.

---

As a user, I would like to be able to get a list of comments from a specific user.

Seems simple - but I haven't yet written the common framework these commands will run through. I guess this is another user story:

As a developer, I would like an interface to the database so I can produce lists that the user requests from a command line.

Oops - there's now a dependency...

How is Independence achieved in situations like this?

Answer 1

Who will use the tool you are building? What do they want it for? That information drives your user stories and not the technical implementation.

The stories you give as examples miss the important element of why.

Are you sure there is only one type of user? Does everyone use the tool in the same way?

For example:

As an administrator I would like to get a full list of users so that I can send out an email about changes to the product

I think that if you write the stories in a more user-focused way you find it easier to make them independent.

Having said that, it is not unusual for there to be some common framework as you mention. But you don't have to write a user story just for that. Instead, write your stories in the usual user-focused way, but expect the first one you do to require a lot more work than the others as it will include the building of some of the common framework.

In this way there is an impact on your estimates of the size of the stories, but there is no impact of the implementation on the user stories themselves.

Answer 2

In my experience, there's always a certain degree of dependencies between stories. It might not occur in the first iteration of identifying the backlog items, but as we start breaking the stories to smaller stories, you'll start seeing those dependencies. Your example clearly shows this situation. I think this is normal and not something we can avoid completely.

If you really want total independence, you should refrain from breaking down stories into multiple dependent stories. Once you start seeing those dependencies, you should create a sub-task instead. Just for the purpose of explicitly stating what needs to be done to complete the story. This way, dependency will be isolated as sub-tasks of each story and you'll avoid the risk of having dependent stories.

On a side note, I personally think that total independence is not what the INVEST mnemonic aims for. We should simply minimize the amount of dependencies so that each story can be moved freely between backlog and sprints. This flexibility is important during Sprint planning. This is the reason why we need more independent stories. Forcing total independence to work might not add anything for that purpose.

Answer 3

In agile project typically you have sprint 0. Which basically about creating architecture, interfaces, and maybe minimum viable product.

When it comes to user story's it's a good practiсe to incorporate all tech stuff in it.

It should do the trick in your case. But you can't get rid of dependencies at all. That's why agile uses themes and epics . Also it's wise to map the storys for complex processes.