How can we map use cases to stories?

In agile development there is no right or wrong. Both Use cases and user stories are offshoots of agile methodologies. User stories have a XP and Scrum backgroung and
use cases dont.

Use cases tend to be a written level contract ( sometimes ) too detailed, sometimes not. There are typically few main sections to a use case. A use case Summary, actors, main scenario, alternate scenarios

There is no one to one mapping of a use case to a user story. Summary is like a story defintion. A use case can break into many small stories.

The main scenario in itself is a story with the actual line items in a main scenario becoming the acceptance criteria. The alternate scenarios become either thier own stories or in some cases simply acceptance criteria.

Both use cases and user stories are as good as the effort put in to write them. Both can turn fairly quickly to a rather mundane and useless document.

Here is an example of a use case broken into stories and acceptance criteria.

USE CASE FORMAT

Use Case Number -1

Actor – Bank customer
Summary – Customer withdraws dollars from his / her bank account.

Main Scenario

  1. Customer inserts debit card into an ATM machine
  2. ATM machine asks for a four digit pin
  3. Customer enters the pin
  4. ATM machine verifies the pin and it is valid
  5. Customer enters the amount
  6. Since there is enough bank balance, ATM dispenses the amount and debits the account.
  7. ATM gives the card back to the customer
  8. Use case ends.

Alternate scenario

4a) Four digit pin is invalid, ATM machine gives an error and asks the user to retry.
6a) There is not enough balance is the account. ATM machine gives a corresponding message

USER STORY FORMAT

As a customer i want to withdraw some dollars from the shop so that I can buy things i like.

Acceptance Criteria.

1) The customer should be able to enter a pin number. IF the pin number is vali the system should prompt the user for a dollar amount to withdraw.If the pin numer is invalid or there is not enough balance the sytem should show a error message.
2) If there is enough balance the system should dispense the cash and debit the account.

As noticed in the example a user story is converstional and conveys the same thing a use case does. It is a small card , with a conversation that is the acceptance criteia.

In case you need to use use cases use the use case as a start and break them down to stories. If done well, stories should be enough detail for the team to develop the system.