1

How do you express what to do when error occurs in a user story? Should the response to what happen on errors be in a task of the original user story, or should I create another user story that is concerned with what happens on errors?

E.g.

  1. This says nothing about what to do on errors such as credit card is invalid, not enough money, …

    As a buyer I want to pay for the order with a credit card to get immediately access to the services.

  2. I could add another user story like this:

    As a buyer I want to get information about errors during payment immediately so that I can fix the errors and try again.

Which of these is common/correct? Should the error handling be part of the original user story?

Improve this question

7 Answers 7

Reset to default
7

You'll get a lot a conflicting opinions on this one.

I typically like to specify happy-path behaviour and error behaviour in a single story unless that suddenly makes the story too large to work on. If error behaviour is complex then it should be its own story.

My favourite way of clearly specifying what is expected in a story (just happy-path, or error-path as well?) is by using Acceptance Criteria.

I don't consider a story to be implemented until all its Acceptance Criteria have been implemented.

In the case of your example, these could be:

Given I'm at the payment page,
When I pay with a Credit Card,
And the payment is accepted,
Then I expect access to the Services

Given I'm at the payment page,
When I pay with a Credit Card,
And the payment is declined
Then I expect a payment declined message
Improve this answer
1
  • 2
    Yes you are right but it's important to group all "creditcard payment" stories in one deliverable feature/epic whatever you name it. Because for business it's unacceptable to have one story (the happy path) delivered without the error path. So you need a system which makes sure you don't deliver a piece of it because it can harm. Some example I found here: iserialized.com/features-vs-user-stories-in-scrum See also the follow ups.
    – Luc Franken
    Sep 22, 2014 at 21:39
4

The handling of errors should be spelled out in the acceptance criteria, not in the story. The user story is all about functionality delivered to the end user, and presumably you aren't delivering errors to the end user.

I can see a case for making error handling part of the story for a product that is targeted toward other developers, where error codes and error handling are actual features that you're delivering.

Improve this answer
1

The point of taking a story-based approach is to deliver customer value incrementally. Ideally, you'd use practices like pairing and TDD so that the code can evolve incrementally as well.

That means that stories should be as minimal as possible, and therefore I'd break the error handling out into a separate story. It's hard to write the details of the error-handling of a story until you've done the story, so it's easier to put that off.

As a better explanation of why, say that I have 5 stories that I need to do before I can get feedback from my customer. The more minimal I can make those stories, the quicker I can get them done and the quicker I'll get feedback. Whenever I get customer feedback, there's the chance that it will invalidate the work that I've already done, so I want to minimize the amount of work that it might invalidate. For your credit-card page, I would gladly demonstrate a page hooked up to a fake service to decrease my time-to-feedback.

The other advantage of more stories is that they are easier to fit into sprints. If the mainline is done and the error handling isn't, I can consider that "done" for the sprint, but if it's all together I'll have to split them apart, which is often problematic.

Finally, teams just feel better getting two small things done than one big one.

Improve this answer
0

As most other answers i only use the Happy_path or "main success scenario" for the description of the User_story

After that I add Scenarios that describe differences to Happy_path as alternatives and errors

Example

  • (a) payment with Creditcard (Successfull)
  • alternatives:
    • (b) same as (a) but Creditcard is from a foreign country
  • errors that cancel the transaction:
    • (c) same as (a) but Creditcard is Expired
Improve this answer
0

Write your story. If there is lots of error handling, split it up into 2 stories. After all, the business value of completing the happy path is different than the business value of understanding the reason for an error.

Add acceptance criteria that focus on the happy path(s) for each story or the 1 big story. If you have a story for error handling, then your AC describe the happy path errors.

If an exception case has a significant impact to the business consider putting it in the AC if you write one big story, but don't try and list every edge/error/exception scenario

Let your QA resources worry about the majority of edge/exception cases and let them document these via test cases. They should also be understanding your acceptance criteria and generating the positive test cases from those.

When possible, try and automate as many of your test cases a possible BUT, be risk neutral. Automating everything is costly; consider if some cases are not worth automating.

Improve this answer
-1

No, you should just create one user story with WHAT the user wants and what is his goal. The user doesn't care about errors, so it shouldn't be a part of the story. But you should always estimate time for error handling, because it takes time and you would want that time to show up in your burndown chart.

Improve this answer
5
  • Error handling for something basic like "I want to enter a date into the system" should be implicit, so this answer is correct for that. For a process such as credit card processing (example from the question) where errors must be handled in a specific way per industry guidelines or government regulation is different. MetaFight's answer is the correct one for a scenario where error handling is an important part of the requirement.
    – user22815
    Sep 22, 2014 at 17:33
  • So you are suggesting to ignore the 90% of the time part of development to get the 10% working. You sound like a lot of developers I prefer not to work with. They tend to be "done" in 10 days but spend the next 90 days getting their stuff to actually work.
    – Dunk
    Sep 22, 2014 at 18:41
  • @Dunk You're not understanding correctly. A user story represents what the user wants to achieve. The user's goal. He doesn't care about errors. So it shouldn't be a part of the user story. Although you should create a task for error handling and estimate time for that.
    – Gaui
    Sep 22, 2014 at 20:31
  • 1
    @Gaui:The user stories frequently ends up being the system requirements and not just what the user wants to achieve. If you are not going to create a separate requirements document then the user story is the place to capture the requirements, including what happens when errors occur. I have never worked a project where it was sufficient to simply capture the "happy-day" requirements, but I've also never worked a project where it was ok to deliver an application that wasn't fairly robust either.
    – Dunk
    Sep 23, 2014 at 16:07
  • @Dunk Thank you for this information. Of course the system requirements have to go somewhere. Sorry about that. :)
    – Gaui
    Sep 23, 2014 at 18:09
-1

All the requirements to make a user story acceptable including errors should be mentioned in "Acceptance Criteria" of the user story. It's responsibility of developer to work with the and discuss all the scenarios pertaining a user story with product owner. Usually by having detailed discussions acceptance criteria of the user story evolves.

Improve this answer
3
  • 1
    this seems to merely repeat points made and explained in a prior answer
    – gnat
    Dec 11, 2014 at 20:21
  • well, no one mentioned that it's responsibility of the developer to raise the question..to come up all kind of scenarios..I think it's a very important point. This problem is so prevalent. I know acceptance criteria was mentioned earlier but real problem is bringing those points and questions to product owner so he could update acceptance criteria..i hope you don't discourage to give answers..
    – Mobeen Siddiqui
    Dec 11, 2014 at 20:31
  • per my reading, it was also addressed in that prior answer: "I don't consider a story to be implemented until all its Acceptance Criteria have been implemented"
    – gnat
    Dec 11, 2014 at 21:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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