Most Agile methods today, use 'product backlog' to track requirements. A product backlog is an ordered list of deliverables. The most widely accepted form of listing these deliverables is User Story.
What is a 'User Story'? Mike Cohn defines it as 'A simple description of a feature told from the perspective of the person who desires the new capability'
An agile team is supposed to complete one or more user stories in an iteration.
That puts another constraint on user stories. They should be small enough so that they can be estimated and worked upon by a team in two to four weeks. So a user story, is not just a 'feature that a end user wants', but also a 'unit of work' which can be estimated and used for planning.
There is a tension between these two aspects. Agile teams, many times fall in trap when one is given more importance than the other. If 'User Value' is always asked for, the work items might become too big and there is a danger of it spanning multiple iterations. If small work items are created directly, there is a danger of losing big picture or 'context'.[2]. Experienced Agile teams generally create smaller stories and use techniques like 'Story Maps' to fill in the context. The larger stories which the smaller 'work item' stories map to are called 'Epics'.
There is another aspect of 'User Story'. Its supposed to be a reminder to have conversation. Its not just a documented requirement. The understanding of what needs to be built is dependent on the quality of the conversation which developers have with business people. But how do you make sure that the discussions which actually produce these stories are guided correctly?
'Agile' requirements gathering needs a framework to allow business people and developer to talk. For guiding these talks, the best approach is to discuss scenarios of end user interacting with the system.
And thats what a 'Use Case' is! Every use case exists because it helps achieve some actor a goal. We start with high level user interactions with the system. For every action that the system performs, we dig more and try to figure out why we have this step? Who wants it? (who is the actor) Why? (What’s the goal?). After we break down a high level flow into more granular ‘goals’,we have a set of use cases.
We first concentrate just on the happy path of the use case. A use case happy path is not more than 3 to 7 steps. Generally, lesser steps. its better.
Lets take an example of use case for a flight booking system. At very high level, following is the summary of user actions. This is called as a 'Summary level' use case.
User goal - Book a flight.
Lets detail out 'Search Flights' use case.
User goal - User wants to get all possible flight options for travel
The main driving factor for product backlog items is that they should be small enough to be worked upon in an iteration (2 weeks). Items like these help in release planning and also provide enough guidance for developers to work on.
These deviations are source of additional backlog items
An curious case where happy path scenario is too big a story for an iteration
To start with we had a backlog item called ‘search flights’. Discussing the happy path with developers, we think that in one iteration, we can do the work to display required fields and find airport codes for airports that user has entered. Finding these airport codes requires us to integrate with a system which has all the airport data available.
So we break down our first backlog item ‘Search Flights’ into two backlog items as follows.
References:
Alistair Cockburn has a very nice presentation, which talks about how use cases can be used in Agile projects at http://alistair.cockburn.us/Agile+Use+Cases
Jim Coplien’s book ‘Lean Architecture’ has very good explanation of how Use Cases help in Agile and Lean development.
Books 'Patterns of Effective Use Cases' and 'Writing Effective Use Cases' should be 'must read' for Agile BAs along with Mike Cohn's 'User Stories Applied'.
What is a 'User Story'? Mike Cohn defines it as 'A simple description of a feature told from the perspective of the person who desires the new capability'
An agile team is supposed to complete one or more user stories in an iteration.
That puts another constraint on user stories. They should be small enough so that they can be estimated and worked upon by a team in two to four weeks. So a user story, is not just a 'feature that a end user wants', but also a 'unit of work' which can be estimated and used for planning.
There is a tension between these two aspects. Agile teams, many times fall in trap when one is given more importance than the other. If 'User Value' is always asked for, the work items might become too big and there is a danger of it spanning multiple iterations. If small work items are created directly, there is a danger of losing big picture or 'context'.[2]. Experienced Agile teams generally create smaller stories and use techniques like 'Story Maps' to fill in the context. The larger stories which the smaller 'work item' stories map to are called 'Epics'.
There is another aspect of 'User Story'. Its supposed to be a reminder to have conversation. Its not just a documented requirement. The understanding of what needs to be built is dependent on the quality of the conversation which developers have with business people. But how do you make sure that the discussions which actually produce these stories are guided correctly?
'Agile' requirements gathering needs a framework to allow business people and developer to talk. For guiding these talks, the best approach is to discuss scenarios of end user interacting with the system.
And thats what a 'Use Case' is! Every use case exists because it helps achieve some actor a goal. We start with high level user interactions with the system. For every action that the system performs, we dig more and try to figure out why we have this step? Who wants it? (who is the actor) Why? (What’s the goal?). After we break down a high level flow into more granular ‘goals’,we have a set of use cases.
We first concentrate just on the happy path of the use case. A use case happy path is not more than 3 to 7 steps. Generally, lesser steps. its better.
Lets take an example of use case for a flight booking system. At very high level, following is the summary of user actions. This is called as a 'Summary level' use case.
User goal - Book a flight.
- User searches for a flight specifying source, destination airports and travel dates.
- Travel website displays flights matching user criteria
- Travel website accepts traveler information and preferences to build Itinerary
- Travel website stores traveler preferences and presents payment options
- User enters payment details
- Travel website processes payment and books flight
Lets detail out 'Search Flights' use case.
User goal - User wants to get all possible flight options for travel
- User visits travel site.
- Travel website presents fields to enter departure, arrival airports, date of travel and travel time.
- User enters required information.
- Travel website communicates with GDS and presents list of available flights.
The main driving factor for product backlog items is that they should be small enough to be worked upon in an iteration (2 weeks). Items like these help in release planning and also provide enough guidance for developers to work on.
A happy path scenario of a use case makes a good backlog item(read use story). Its extremely important to really really think about minimal happy path scenario. ‘Individual and Interactions’ help here.
A minimal happy path scenario, makes a perfect backlog item.
A minimal happy path scenario, makes a perfect backlog item.
Once we have happy paths, use cases naturally help thinking about deviations.
Each deviation, then can become a good product backlog item. (User story).
So, following is the first cut backlog that we come up with
- Search Flights
- Store traveler information
- Process payment
- Book flight with GDS.
Brainstorming deviations.
Once we have basic happy path scenarios, for each use case we think of deviations.
User goal - User wants to get all possible flight options for travel
Main Success Scenario:
- User visits travel site.
- Travel website presents fields to enter departure, arrival airports, date of travel and travel time.
- User enters required information.
- Travel website communicates with GDS and presents list of available flights.
Deviations:
3a1 User enters wrong origin or destination
3a2 Travel website presents possible airport code options.
4a1 No flights are available matching criteria
4a2 Travel website presents appropriate message
An curious case where happy path scenario is too big a story for an iteration
To start with we had a backlog item called ‘search flights’. Discussing the happy path with developers, we think that in one iteration, we can do the work to display required fields and find airport codes for airports that user has entered. Finding these airport codes requires us to integrate with a system which has all the airport data available.
So we break down our first backlog item ‘Search Flights’ into two backlog items as follows.
- Accept flight search criteria and build search request. [Use Case step 2 and part of step 4, and deviation 4a]
- Search flights with Sabre GDS. [Use case step 2]
- Store traveler information
- Process payment
- Book flight with GDS.
- Provide airport options to user.
We included step 4a, (no flights found case) in the first item as developers thought it will help them build a vertical slice through the system.
From the above example we see that the Use Cases provide a very good thinking and brainstorming framework for discussions between business people and developers. 'Agile' teams should not deny a lot of wisdom that's already available with Use Case community.References:
Alistair Cockburn has a very nice presentation, which talks about how use cases can be used in Agile projects at http://alistair.cockburn.us/Agile+Use+Cases
Martin Fowler has a nice paragraph discussing relationship between Use Cases and User Stories
http://martinfowler.com/bliki/UseCasesAndStories.htmlBooks 'Patterns of Effective Use Cases' and 'Writing Effective Use Cases' should be 'must read' for Agile BAs along with Mike Cohn's 'User Stories Applied'.
