Do user stories need to be Independent and Valuable or Independently Valuable? [duplicate]

Question

This question already has answers here:

Splitting user stories into smaller stories (2 answers)

Closed 1 year ago.

I am trying to split down user stories for a brand new system. This system will record weight readings from a balance connected to a serial port.

Due to regulatory data integrity requirements - the data must be attributed to the user who produced it. The business cannot possibly use the software without meeting this requirement.

In order to meet these requirements we initially wrote a single story covering both login and data recording but this seemed a little large so we tried to split it as follows:

1) As a lab technician, I would like to be able to record weights electronically without transcription so that I do not make mistakes when recording data.

2) As a QA officer, I need data recorded by users to be attributed to them via their windows credentials so that we can comply with <relevant data integrity guidance>.

Applying INVEST to these new stories gives us some issues. These stories could be implemented independently but are valuable only in conjunction with each other.

• If we build just story 1 it seems not to be valuable, because the business could not possibly accept the system without meeting data integrity regulations, therefore no user can gain value from it.
• If we build just story 2 (a login function), a system you can log in to and do nothing provides no value.

Is this a valid way of splitting or do the stories also need to be independently valuable?

Answer 1

Each story should be valuable independently. But don't get too hung up on it.

The idea is to avoid partial functionality. ie spending ages doing something and being unable to demonstrate any progress towards the project goal.

So for example say I have an ecommerce site project with a Login story and a Purchase story. Obviously I need both to have a functioning ecommerce site. But if I do Login as a separate story I can demo it at the end of the sprint and its a task ticked off the list. Yay! I know we needed a login page and now I can see it working! look at the progress!

A counter example might be "Install the database server". There's nothing about having a database that a customer/product owner/stakeholder will care about. Sure you need one, but only as an implementation detail to some other story. Boo! I told you guys I wanted a website not a "database"! how long until you are finished?!?!

In your case I would specify the auditing requirement in two parts.

1. As a stand alone story for the person who needs to look at the audit data:

   "As an Auditor I can read/download/export the audit trail on 'the things' in order to meet 'the regulations'"

2. As a non functional requirement/DoD on any other stories that have to record the data

   "Must record X Y and Z to 'the audit system'"

Answer 2

Context is king.

A story that happens after authentication is dealt with somehow is still a useful story. You do not have to bake a fully detailed authentication story into every user story simply because you're required to always authenticate.

Also, your authentication requirement is only "always" in certain contexts. Your software and procedures might be reusable in other countries, under different laws, or in different fields where those laws don't apply.

None of this says you don't authenticate when required. Just don't spread around that idea if you don't have to. Otherwise if it ever changes in any way it will invalidate a lot of your work. Express how authentication is done in one place. Change how it's done in one place. Both in your code and in your design documents.

Answer 3

I think the heart of your problem, at least in this particular example, is how you decomposed the story. To me, the story about the QA officer needing to have data recorded isn't a story. There may be stories around how the QA officer queries, views, and exports data. But the fact that data is recorded seems like it would better fit on the story or stories where data is created, updated, modified, or deleted (and in regulated environments, "deleted" is probably a soft delete and not a hard delete).

By using acceptance criteria like this, rather than splitting to stories, you ensure that each story (and it's associated acceptance criteria) are valuable and the entire scope of the work is captured and can be understood by the team in one place.