Search code examples
project-managementagilescrumagile-project-management

Mapping all Use Case flows of action to User Stories

I'm attempting to write my requirements out as User Stories. Moving from a waterfall world, I am much more familiar with Use Cases.

One of the things I like about Use Cases is each interaction with the system is well-defined, as well as all the alternate and exception flows of action.

UC-01

Success Scenario:

  1. The user navigates to the customer
  2. The user clicks the Add Contract button
  3. The user fills in the Contract Name, Contract #, Start Date and End Date fields
  4. The system asks for confirmation
  5. The user fills clicks the save button, and the contract is saved

Exceptions

5a. The user aborts, and the contract is not saved

Alternate flow

1a. The user uses the filter to select the customer

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

Solution

  • 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:

    1. 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.

    2. 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.