how to split a story with cascading side effects

Question

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.

1. requires schema changes
2. requires migration changes
3. requires api changes
4. it changes from 1 book to many books, so the profile UI needs to be updated to show multiple books.
5. 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.
6. it changes the logic of our export users feature
7. it changes the logic of our import users feature
8. 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?

Answer 1

First of all, try not to get to attached to the user story format. It's useful to capture a requirement from a user's perspective, but then it starts to get in the way when you start to think at the actual solution that you have to build and all the technical implications, because doing things like API changes, schema changes, etc. is not something a user cares or even thinks about.

You can start with a few user stories that reflect what the user can do when you move from one book to multiple books, and then see what might be required in each case and in what order you might do them.

Then, something like INVEST doesn't mean you don't have dependencies, it just means you should try to reduce dependencies as much as possible. You will always have dependencies and features that build on each other, you just have to be mindful to not develop with too many dependencies at once (more dependencies, more problems; less dependencies, less problems).

It seems you already identified the kind of changes that are needed. Now it's a matter of deciding on the order. And you decide on that by asking "what is some small change that I can introduce to keep everything working the same?"

You could change the schema for example, to support multiple books. One book fits into a schema that supports multiple books. All layers above it that store and retrieve one book, don't really need to know or care that the schema could now support more. Nothing changed for them.

Then you might change the export to export more books, but because nothing else changes, you will still be exporting just one book. Import will work the same because of that.

Then you change the import to handle more books, and things still work. They work with one book still but now schema, import, and export are prepared to handle more books.

Then you think "what is some small change that I can introduce to keep everything working the same?"

You get the idea.

At some point you will be making the changes that actually handle multiple books and everything you've previously built is there to handle them.

So that's how you split them.

The fact is that, even if you build everything in a big bang effort on a separate branch, and then replace everything in one move, you will most likely still build it in a similar way. You might pay less attention to making sure things still work after each change, since you are building things on the side, in isolation, but order and dependencies of each step might be similar.

The advantage of building incrementaly is that you find out about issues earlier than with a big bang approach, where things either all work, or don't.