Use Cases come from the Unified Process and are the main mechanism for communicating the requirements of a project as a system of interactions between users, systems and the features that need to be implemented. They are usually dominated by happy paths and unhappy paths. One of the areas where they are good is that they identify prior system state, the changes on the system and the end state of the system after the action has occurred. Unfortunately they tend to be large in length, growing exponentially and cause all manner of other use cases to be written in support that they grow beyond the ability of developers to manage or control them.

User Stories are kind of equivalent to a one sentence summary of a use case with one path as the outcome; such as a happy path. They are also done from a, or multiple, user perspectives. Some advocates of agile methodology have argued that a user story in conjunction with the acceptance tests constitutes a Use Case; though this assumes that the Use Cases in many organizations do actually think and write out the alternate paths to the happy path.

The other difference between the two is that a Use Case is intended as a history of the system and used to describe the system in the functional documentation at the end of a project. User stories are far more throw-away and don't survive the scrum board.

Use Cases tend to be long and grow cruft. Once they obtain a certain length they become unusable and short sentences are usually used to convey what a use case should do rather than constantly referring to the use case itself. User stories are easier to move around the scrum board, or hand around. They are also smaller.

Another method, and one I prefer, is the semiotics of BDD which is another permutation of the user story, called scenarios, in such a way that the task is instantly testable. We already spot our unit tests with;

//given

//when

//then

We put our mocked objects and expectations in the given, perform the operation after the when, and then test with assertions the change in state of the system after the operation through assertions.

The BDD style of scenarios are unambiguously testable at all parts of the project, from automated engineering tests, to hand run QA tests, to users in production that will be doing the same tasks on the system.

More Reading on Agile

• Agile
• Agile Training
• Differences Between Use Cases, User Stories and Scenarios
• Scrum Wall
• Book Review: Lean Software Development by Mary and Tom Poppendieck
• User Stories for Nanotoa
• When to Fix Bugs in Agile
• Behavorial Driven Infrastructure
• Lean Development and Elimating Waste in Projects
• Lean Development and Waste: Debugging Environments