Splitting up user stories that are enhancements that may destroy other functionality?

Question

We are implementing an epic. While refining this epic, we discovered that a lot of our current functionality will be impacted.

I understand that when splitting up user stories, we should vertically split stories for various reasons.

A few of the techniques to do this is to

• split by workflow
• split by happy path/sad path
• split by roles
• etc

However, upon splitting up our stories this way, we discover that upon delivering some user stories, other existing functionality will be left non functional. How do we handle this situation?

I am currently thinking of 3 options

• disable all the existing functionality related to the epic
• let them be and them being non functional is out of scope (known issue, will be fixed in future release)
• let the features exist in parallel, and disable the old one once new one is complete

How should we go about this?

Answer 1

Very interesting problem. All three of those are potentially options, but the third seems the most likely. I could see the first if for some reason there was business benefit to stopping people using a set of features for a while (for example, if some regulation made the use of those old features unacceptable). The second might fall into the "no harm no foul" category if you aren't going to production, but then you don't have an increment of releasable code. I would only do this if the cost to #3 was so high that it was the only sensible business option.

So on to #3: this is basically a feature toggle. You send your app down the old path unless this feature is toggled on with a config setting or some attribute sent in the browser. When you're ready to completely switch over, you permanently toggle the new feature on and clean out the old stuff after. A good feature toggle will allow both paths to work successfully. However, there is extra effort that goes into doing this. That effort might be small (like if you already use this approach and have everything built with this option) or very expensive (like if you have a complex 30-year-old mainframe app). I've never seen a case where it was impossible, but I have seen it be prohibitively expensive and that's where #2 comes in.

Answer 2

There's no pure right answer to this. It depends on your business/schedule/PO constraints and priorities.

disable all the existing functionality related to the epic

This is good if either a) you're confident you don't have to release an increment until the epic is done, or b) there is no substantial loss of business value in temporarily disabling the functionality

let them be and them being non functional is out of scope (known issue, will
be fixed in future release)

This is good if you're confident you won't have to release an increment until the epic is done.

let the features exist in parallel, and disable the old one once new one is complete

This is the least risky course, if you use a flag to select the code path. That way you can disable the old one for development, and disable the new one if you have to release before you're done.

Another possibility would be to revisit splitting up the epic to see if you can avoid this problem. Especially since you say that you didn't realize until after you had done the split that the existing features would be affected, it might be worth spending more time to look for a better solution.

However at this point I would consult with my stakeholders, especially those who make decisions about schedule. If they're cool with one of the three options you laid out, great; if they want you to try another split, ask them how much more time you should spend trying to do that before concluding there is no way.