I have a question about story writing, side effects, and splitting stories regarding this example below.
The customer requests a feature that requires a relationship change between some entities in our system.
For example, let's say that a User could list their favorite book in their profile. But the customer now wants to allow the user to list all their favorite books in their profile and book now becomes an entity with other fields, instead of just a name.
So, i create a user story for that. "As a user, i want to add all my favorite books to my profile so that everyone can see my favorite books.".
The team looks at this story and determines it is far too broad because it require changes in many different areas for this to work. Below are examples to get the point across.
- requires schema changes
- requires migration changes
- requires api changes
- it changes from 1 book to many books, so the profile UI needs to be updated to show multiple books.
- it changes from 1 book to many books, so the profile UI for updating your profile needs to change to support the entry and updating of multiple books.
- it changes the logic of our export users feature
- it changes the logic of our import users feature
- it changes many other tables and views on the client that were listing users with their favorite book, now they will need to list many books.
While we try to figure out how to handle this process in the future, we decided to just move forward with the following process:
We created an Epic "Multiple Books" and assigned it some stories: "As a user, i want to add all my favorite books to my profile so that everyone can see my favorite books." "as a user, i want all my favorite books exportable so i can import my favorite books into other systems."
But doing this, created this weird issue where we broke INVEST. These stories are not Independent. One of these stories needs to make the backend changes to support this feature. If we implement the backend changes in the first story, the second story now relies on the completion of the first story.
The ultimate question: How have you dealt with this type of Story that has side effects on your teams? Where the introduction of a new feature causes cascading changes throughout the software? And how do you split this type of story into smaller stories?