Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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"?

share|improve this question
    
Do those apply to ALL user stories or only selected few (but still a lot)? And "system catches exception, and shows info to user" is too specific to be part of user story. –  Euphoric Jul 13 '12 at 6:14
    
@Euphoric They would apply to the great majority of stories; all stories that involve UI and data store e.g. –  ProfK Jul 13 '12 at 7:50
add comment

3 Answers

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.

share|improve this answer
add comment

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.

share|improve this answer
    
I like this, even if it doesn't resolve to only one, maybe I could use. "as a user, I would to see these errors like this", "like to be emailed on those errors" etc. But I'm using a tool that requires US's to be under a feature. I would then have one featire for the few error user stories? –  ProfK Jul 13 '12 at 12:13
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.