Agile User Story Splitting: Error Handling & Logic + Interface Variations

By: Strategic Services Team | December 1, 2020

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.

 

agile transformation ebook

Core's Strategic Services team of Project Managers, Scrum Masters, and Business Analysts provide mission-critical leadership to guide our clients' projects to success.

Subscribe to our Newsletter

Stay informed on the latest technology news and trends

Relevant Insights

How to Turn Your Software Licensing into a Strategic Asset

Most people groan when they hear the words “software licensing”. Licensing can be complicated, and usually businesses will continue with...
Read More

How to Manage Your Hybrid Workforce with Compliance

The pandemic accelerated a real change in the way people do their work. Before, employees worked in a physical office...
Read More

Windows Server 2012 End-of-Life Risks, Options, and Next Steps

In October 2023, Windows Server 2012/2012 R2 will reach the end of extended support – leaving your infrastructure and applications...
Read More
X