How to split Requirement into Userstories

Question

My team is currently working on defining user stories with the product owner. He supplied us with a story that is on one hand quite complex, on the other hand he says, that no part of it is independently of value.

I would like some hint on how to do this in scrum:

Our field is a register for last wills, the users are people who search for and handle last wills for deceased citizens.

Our stories now are:

Story 1:

A User wants to enter Filter criteria to get at max 100 results from the Database at once. (business process = "send inquiry")

Acceptance criteria:

results are digitally signed according to law xY max 100 rows at once a button for "the next 100" last Name, given Name, as possible filter criteria

And then there is a second story:

Story 2:

An Auditor wants to review all "inquiries" sent by a defined user, to see if he entered legally correct filters, see what results were provided at the time of the inquiry, and see if the user handled all results properly (legally).

Acceptance criteria:

results are digitally signed according to law xY Story 1 criteria as possible filter criteria ( action would be: "give me all inquiries where the user filtered for "given Name"="Bob"") show the same results as the user saw at that time results never change

SO if my team now decided to tackle Story 1 now, but Story 2 on a seperate sprint:

How I have to handle these "inquiries"in Story 2 obviously influences the implementation of Story 1.

It is even legally not allowed to deliver a final product with story 1 but not story 2 (these reviews are mandatory once a year for each user)

Are these one story? Does scrum encourage just implementing Story 1 with no regards to story 2 and possible having to rework Story 1's result to enable Story 2? Do I add "inquires have to be stored with filters and results" as an acceptance criterion to Story 1 and reference Story 2 (that would break the "independent" requirement of the INVEST principle)?

My main question is:

If two stories have potential(or are sure to) to influence each other, but cannot be completed in the same sprint, do I:

1. disregard the second story's influence (need to redo work, but decide as late as possible)
2. merge the stories (make it more complex, but delivering the full business value of the features)
3. Plan the influence into the implementation (no need to refactor - possible time saved later, but no longer independent stories, working against the "embrace change, decide late" principle)

All courses i took and free videos I watched, papers I've read did not give me a satisfying answer, I really need your help here.

Thank you in advance!

Answer 1

Scrum basic principles are iteration and incremental delivery. I base my answer on these principles.

The stories should be small, simple and describe a testable piece of functionality. The stories you describe should not be merged. If you know in advance some functionality that may be needed by other stories, you can add it as an acceptance criteria for example "The criteria entered by user should be stored for auditing purposes".

If for some reason the influence of other stories is not known in advance you will simply create a new Product Backlog Item for the missing functionality once it is identified.

Also, the stories can be delivered for testing independently, but delivered to production in one batch.

Answer 2

Short answers:

1) / 3) Depends on the System, YAGNI sais don't do it, but I think in some cases it might make sense to have the other story in mind.

2) Dont't do it, keep your stories as short and simple as possible.

Long answer:

You are right, Stories should not be dependend on each other (See INVEST), but sometimes this is not possible.

Release whenever appropriate

Source: How often to release in Scrum sprint

I think a missunderstanding here is, that a MVP (Minimum Viable Product) after a sprint does not mean the feature must be released to public - it is potentially shippable, meaning: working as expected and it fullfills all of your QA criteria.

So in my eyes, it is totally fine to implement story 1 and show it to the customer. If, for legal reasons, it can't be released, customers have to wait for story 2 to be completed

FYI: I also think your Stories seems not to be ready. Story 1 misses the "why" part and has two requirements (filtering and paging). I would split that up. Your 2. story has some acceptance criteria in the story sentence (stop after "... legally correct filters.").

Answer 3

Referring to INVEST, let's look at the two scenarios:

1. Treat Both User Stories Separately
2. Combine Both User Stories

Let's consider impact to the system which is introduced by the requireemnt that the auditor must see the exact same results as the user and be able to track the user's interaction. One might argue that this merely sounds like an additional logfile but if one needs to consider efficiency aspects, it is likely going to influence at least an assumed database's data model. It could also involve legal privacy aspects.

In other words, it has the potential to require fundamental changes.

Then to what INVEST criteria evaluation does that lead us? I believe it's something along the lines of:

Treat Both User Stories Separately

Independent (should): --
Negotiable  (should): +
Valuable      (must): +
Estimatable   (must): --
Small       (should): +
Testable      (must): +

Combine Both User Stories

Independent (should): ++
Negotiable  (should): +
Valuable      (must): +
Estimatable   (must): o
Small       (should): +
Testable      (must): +

Reasoning:

• Estimating the effort for potentially having to modify central underlying aspects of the system must be possible at all times.
• The independence of PBIs may be sacrificed, but in my view, the tradeoff must be considered.

Final Remark:

Regardless of the project management approach, I feel it would be best to clarify the related auditing requirements to a suitable degree before implementing functionality which may have to undergo major rework later.

The above comparison appears to support that point by enforcing the implementation of an auditing functionality along with related user functionality.