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.
-
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.
-
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?
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
1
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.
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.
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
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.
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.
5
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.
3