How do I treat application aspects with regard to features and user stories?

Question

When drawing up a backlog, I have several requirements that apply to a great many user stories, i.e. aspects of the application like error handling and feedback. How do I include these (without using an #include directive in each user story )? Should I treat error presentation as a feature, then have user stories for this feature like "system catches exception, and shows info to user"?

Answer 1

Dealing with user feedback is critical to user experience, but also applies to different parts of the application in different ways.

Take the following two examples:

One story might focus on a direct user interaction in which a fatal error occurs. A modal dialog is used to inform the user of the error and notify that recovery is impossible. The story for this would be: "As a user I want to be informed about an invalid entry of some data form so that I can go back and correct this error immediately". This user story implies that this is a fatal blocking error which the user needs to correct immediately.

In a second story the user forgets to enter mandatory data into a form. The story would be: "As a user I want missing fields in an entry to be highlighted so that I know what the required fields are."

This subtle notification is vastly different and cannot be combined with the first story into one general error handling story. However, both can arise from internal exceptions.

Remember that it is important to convey the "what" of a story, so for example the error scenario which should be dealt with in a specific situation. The how of the error (i.e. an exception is being thrown somewhere) is almost irrelevant to the product owner as it holds no business value. From a technical standpoint having a sound architecture is something I would expect from my product in any way.

In the end you will gain flexibility and extensibility by focusing on the business value and have well seperated and small user stories.

Answer 2

I believe solution is good separation of concerns. Things like error handling, logging, feedback and such should be handled globally with only one piece of code. Only requirements, that are different from this global behavior should be noted as either part of user stories, or in discussion about implementation of said user story.

So from project management side, there should be one User Story, that says "As a user I want to see error in a such a way, that allows me to report it to the administrator." or something like that. And this user story should apply as a global rule to all use cases.

Answer 3

One idea (taken from SCRUM): Things that need to be checked for every user story are included into the so-called "definition of done".

Usually "definition of done" includes technical things, like:

• all tests are green
• code is reasonably clean
• code causes no regressions

But it can also include user-visible things:

• no user operation takes more than a second, or
• all GUI controls can be used with the keyboard alone

The team must check the "definition of done" for every user story before they declare it done.

One option would be to include appropriate error handling into this "definition of done". However, as the other answers point out, the examples you cite (errorhandling & feedback) are actually probably not really good examples for requirements that apply "everywhere":

Proper error handling & feedback usually depends on the context, so it needs to be defined separately for the places where it's needed. So in this case it may be better to formulate error handling as separate user stories, as explained by malte's answer.