User Story Splitting – Error Handling and Logic
This is yet another great approach to splitting user stories. Things can always go wrong, but do you really need to deal with every possible error that could occur right off the bat? You could consider deferring adding error handling until later.
When you do get around to adding error handling, you could also question how detailed you need to get: you could start off with a generic message when anything goes wrong, or you could add logic to identify the specific conditions that caused the problem to occur.
The key with splitting stories this way is to make sure you don’t forget to circle back and add error handling later. It’s human nature to get comfortable with the “happy path” experience and to forget that errors can and will occur. It would not be a good experience to entirely leave out error handling. But you can also go overboard with error handling, and that is a time-consuming and expensive proposition. You need to find the “sweet spot” where you’re improving the user experience, but not over-engineering it for your own convenience.
Questions to ask:
- Do you really need to include error handling to begin with, or can it wait?
- If it can wait, at what point do you come back to add error handling in?
- How detailed do you need to get with the error handling? Will generic handling suffice, or do you need to get more detailed?
It’s fine to defer error handling – just don’t forget to get back to it at some point, otherwise your user experience will suffer.
User Story Splitting – Interface Variations
If you have multiple versions of an interface, this is another logical way to approach splitting a story. For example, in my fictional Recipe app, my users might want a printable version of a recipe that doesn’t use color or photographs. Maybe they also want one that will print on the size of an index card, so they can cut it out and put it in their recipe box. And perhaps they also want the full-color version of a recipe to look at when they are using a device to make a recipe.
This is a useful way to split stories. You can start with one interface version and defer others until later.
Questions to ask:
- Do you really need different versions of an interface, or will one suffice?
- If you do need multiple versions of an interface, can you start with the primary one, and defer others until later?
- What will be the most widely used interface? If you know that, then you can start with that one first.
I’ve used this approach many times in my career as a Business Analyst on an agile team. It’s usually easy to determine which will be the most commonly used interface, and which ones can wait until later.
