This question already has an answer here:

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?

marked as duplicate by Doc Brown, BobDalgleish, gnat, Bart van Ingen Schenau, user53019 Sep 19 at 1:22

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 2
    "The business cannot possibly use the software without meeting this requirement" - then it's not a user story, it's part of the definition of done. Every story must do that to be complete. – jonrsharpe Sep 12 at 11:53
  • @jonrsharpe I probably oversimplified a bit there. This particular type of data is a category which causes it to fall under those regulations. This does not necessarily apply to everything we produce for the business, so we can't really put it in the DoD. – Rich Knight Sep 12 at 12:30
  • A small point: “via their windows credentials” is part of a solution, not a requirement. It should not be part of your story. – Guran Sep 12 at 12:57

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'"

  • 1
    +1 for pointing out that an auditor is a user of your system. Auditors are people too, you know! All kidding aside, your end users aren't the only users of your system. – Greg Burghardt Sep 12 at 13:28
  • When determining if a story is valuable, I like to turn the test around: Which (external) stakeholder will start to complain if we don't implement this story. If there are none (like in your database server example), then the story is not valuable. – Bart van Ingen Schenau Sep 13 at 11:45

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.


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.