Describe the categories of users that will perform actions on the system.
- Avoid actors that are too generic or too specific.
Includes the actor’s specific motivation for interacting with the system.
- Goals
- Frustrations
Actors are essential for justifying the existence of features. Can help to identify one of the types of system stakeholder to negotiate requirements with.
A system actor does not need to be a human, though.
User Story Tasks
User stories must be refined into implementation tasks.
Example.
- Add search page to web front end
- Add search page to mobile app
- Add indexes to property database
- Extend API for property search queries
- Add query handling logic
User stories may share tasks. These can be registered as issues on the project
Task Estimation
Estimation of software tasks is difficult
- Some practitioners argue that estimation is fruitless.
- Sometimes necessary for budgeting and wider planning
- Helps identify poorly understood tasks and force refinement Various methods have been proposed
- Delphi methods - Between Experts - Planning Poker
- Market testing (priced to win, bidding) - Announce project, and
- Empirical methods - such as kokomo, using past history
- Algorithmic methods. - use properties of the tasks to estimate
MoSCoW
Must Have- Bare minimum critical features for operation
Should Have- Things that are important, but not technically critical, improve of use
Could Have- Nice things, such as stretch goals, doesn’t make it unusable without it
Would Be Nice To Have (wont have on time)- Potential features that are out of the scope for now
Scenarios
Useful for:
- Describing workflows
- Specifying acceptance tests
Follows an arrange/act/assert flow, similar to a unit test: Given [a fixture] And [another fixture] And […] When [an action is performed on a feature] And [another action is performed on a feature] And […] Then [a condition is holds] And [another condition holds] And […]
Example Scenarios: Given a mocked database of properties And a property search API When a text search is performed for 29 Acacia Road Then Banana Man’s property is returned
Where to Store User Stories?
Some teams keep user stories on hand written postcards stuck to a wall or whiteboard in the team space.
- Easy to reorganise and review as a whole.
- Harder to share across team locations
- Requires effort to maintain.
An alternative is to store user stories and scenarios within the project version control system.
- Better than a separate wiki, as this reduces risk of stories becoming outdated.
- Integrates well with behaviour driven development.
Don’t use the issue tracker to store user stories. Issues describe work to be done, so are useful for tracking tasks.
- Tasks are best stored as issues in the project issue tracker.
To restate, story costs estimates are derived from task estimates, but task priorities are inherited from their highest priority story.
INVEST
The INVEST acronym is a mnemonic used in agile project management, particularly in creating user stories to ensure they are well-formed and useful. Here’s a brief explanation of each component:
- Independent:
- User stories should be self-contained, with no inherent dependency on another story. This independence facilitates easier planning and prioritization without concerning sequence or coupling.
- Negotiable:
- User stories should not be overly detailed and should leave room for discussion. Flexibility in their requirements allows for collaborative and adaptive development during the sprint.
- Valuable:
- Each user story must deliver specific value to the customer or user. It should clearly articulate the benefit provided by its implementation.
- Estimable:
- A user story must be clearly and concisely written so that developers can estimate the effort required to implement it. This is crucial for effective sprint planning.
- Small:
- User stories should be sufficiently small to facilitate easy scheduling and completion within a sprint, but large enough to ensure meaningful progress. This balance helps maintain momentum and manageability.
- Testable:
- A user story must provide enough information to create test cases for it. It should be clear how to tell when the criteria of the story have been met, ensuring a deliverable that meets requirements.
Example Persona: Eilidh the Estate Agent
Goals
- Sell more houses (get commission)…
- …by securing more buyers and sellers for the agency.
Frustrations:
- Customers can’t register for themselves.
- Unable to answer buyer questions on home visits
Example User Story: Eilidh the Estate Agent
As a first time house buyer I want to enquire about available properties that match my preferences So that I can find somewhere to live.
As an estate agent I want to be notified about a new enquiry So that I can follow up with the new client.
Written from the perspective of a system user. Rationale should not be circular on the user story action.
Detailed Example:
As a first time house buyer I want to enquire about available properties that match my preferences So that I can find somewhere to live. Preferences are: • Budget • Location • Number of bedrooms • Off-street parking • Garage • Garden • Type (Flat/Semi-detached/detached/bungalow/land only)
Example User Story: Cricket
As an England cricket team fan
I want to be notified of upcoming matches and be able to filter these notifications by match type (T20, 50-50, Test). Once I’ve been notified, I want to be able to retrieve all the match information, such as who is batting, what the score is, who is bowling, how many overs have been bowled and so on. Once I’ve got the detailed view, I’d also like to be able to find out about a player’s history, such as their batting statistics.
So that I can keep track of all that is going on with my favourite team.
Example Smelly User Stories
For the estate agency application:
As a user I want to search for properties So that I can find properties.
This user story isn’t negotiable because it lacks an identifiable user. The story isn’t valuable because the rationale is circular.
For a ride sharing app:
As a driver I want passengers to wait at an agreed location So that I can pick them up.
This user story isn’t testable as it is beyond the scope of a software system. A better user story might say “I want passengers to be notified of a collection point.”