How to effectively communicate requirements is an issue that many software development teams face. The objective is usually for the Product Owner to use an effective method to describe to the development team what is to be implemented along with the flow of actions.
Two methods of communicating requirements are through the use of User Stories and Use Cases. Some teams use these terms interchangeably but there are fundamental differences. Lets take a look at the two beginning with Use Cases.
Use Cases describe how a user will interact with a solution to achieve a specific goal. They illustrate the user’s actions as an actor in interacting with a system.
Use Cases can be visual
Or in written description
User stories describe the features, functions and uses of a product that can be interpreted by:
- Developers in order to write the code to implement the desired functionality.
- Designers in order to create the visual layout of the desired interface.
- Testers in order to create test cases to validate the implementation.
- Customers or the Business in order to confirm what they require is what will be built.
User stories are used in almost all Agile projects
Somefields that can constitute a good user story template are:
- Attachments — Scripts, Images. Avoid urls because this would violate in I in independent if the reference document changes, the user story will no longer be valid
- Original Estimate
- Remaining Estimate
- Actual Estimate
- Acceptance Criteria
- Development Owner
- Testing Owner
- Requirements Owner
An effective technique of writing good User Stories, is the INVEST criteria. See more on INVEST here
There’s a consensus that using both Use Cases and User Stories in the same project is duplication of effort and Agile teams should use only one technique.
If faced with a situation whereby both techniques are to be used in the same Agile project, the team should remember the Agile principle of “Simplicity — The art of maximizing the amount of work not done is essential”