Mapping all Use Case flows of action to User Stories [closed]

Question 1

They wouldn't be captured as such.

You are approaching user stories from the wrong angle. Coming from waterfall this is quite a common misunderstanding.

Your story in this example should be something like:

As a user I want to add a contract to a customer so that [insert value here]

From the example you can note two things:

I can't finish it because I have no idea of what the value of this story is to the customer. This is quite important because it drives any negotiation over the story. For example, one doesn't want to spend a lot of time on stories which have a very marginal value.
There isn't much detail. This is on purpose, because the story tries to capture the problem or the opportunity, not the solution. As a user, there are many theoretical ways in which I can achieve my aim of adding a contract to a customer.

The focus of stories is letting the users achieve their goals.

Normally you can write details about how you currently speculate that the story will be implemented on the "back of the card" or in a notes field in your ALM tool, but the point I am trying to make is that stories are negotiable in how they are implemented.

Your developers are expected to interact with your customer representative during the iteration to discuss/prototype/try out the various different possible solutions so that the aim of the story is achieved efficiently and effectively.

A very simple and yet quite exemplary and typical example: what if you forget an edge case, alternate flow or exception? With stories, that's no problem: the developer discovers it, has a chat with the product representative, and they make up a plan to handle it.

You can do this because it's clear that handling these cases is part of the user story. Not so with the requirement, which is prescriptive on what the solution should be, instead of what it should achieve.

Question 2

> Where would the exception and alternate flows be captured in an Agile approach?

A Use Case is a form of feature documentation. This documentation can be created

before implementation (as specificatoin in waterfall)
during or after implementation or not at all (agil)

In Scrum you would just have a feature-request "Add Customer" in the Backlog without the scenarios.

Question 3

Many agile practices do not dictate that you have to write your requirements out as user stories with acceptance criteria. All that is needed is a list of requirements (aka Product Backlog) that is ordered. When giving these requirements to the team in a sprint planning session they should be the minimal amount of information that is still clear enough for the team to understand and build. There is a fine line between doing too little grooming and over analysing the requirement; this takes time to get right.

Having said that, user stories are commonly used as they make sense to multiple parties involved in the process where other forms of requirements are limited to a specific audience; i.e. you have to teach people how to read and understand use cases but do not have to do that for user stories. Obviously writing it is a different problem.

Question 4

I like @Sklivvz and @k3b answers.

Regarding your example.

First: As Sklivvz wrote, the User Story defines the problem and the goal. I differ in the opinion regarding side tracks and exceptions. Those are, in my eyes, small stories to. With there own priority. I.e. the ability to cancel the process could be of higher prio than some validation problem story.

My Answer in short: Write a story for the main goal, side goals, exceptions and alternate flows.

positive side effect: The product owner (you?) has the chance to prioritize those stories.

Question 5

agree with some of the above and would like to add the following (hope this is useful).

Use Cases are not specifically/only related to waterfall, they are merely a means to visual behaviours (use cases) of a system and the relationships between those behaviours and other system behaviours, and external entities to the system (actors).

There is no reason why a user story cannot be further described by use cases and use case scenarios.

Remember, just because you are practicing (I guess, but not restricted too) Agile that does not means you cannot design stuff. Just don't let the design have more value over the result i.e the product (although in complex . safety systems this should be the case).

Question 6

When you capture stories initially, they should be very brief and focused on benefits.

When you've discussed solution with the team and ready to start implementation, you should document it with more details.

I like Given/When/Then format and I'd re-write this Use Case into this (real goal may be different, but still you'll get the main idea):

Title:
As a user I want to add contract to customers so that I can track contracts history

Given customers list
When user clicks to Customer
Then he sees Customer Details view
And Add Contract button
[mockup]

Given Customer Details view
When user clicks Add Contract button
Then he see a popup with fields:
Contract Name - field spec: [default value, max lenth, etc]
Contract # - [field spec]
Start Date - [field spec]
End Date - [field spec]
[form mockup]

Given user filled form correctly
When he click Save button
Then he sees confirmation dialog ["Do you really want to add this contract?"]

[NOTE: I think this confirmation is stupid and not required]

Given user see a confirmation dialog 
When he clicks Yes
Then the contract is saved
And user sees success message "Contract is saved for customer XXX"


Given user see a confirmation dialog 
When he clicks No
Then the contract is not saved
And confirmation dialog closes

NOTE: most likely this scenario is a separate user story

Given home page
When I click Add Contract link
Then I see Contract form
And "Select customer" drop down field

...

As you see, you can quite easily use Given/When/Then format to describe user stories. It is very important to make sure that true value of user story is captured. Otherwise it is very easy to make some decisions that will be really bad from the business point of view.