User Stories
Are your stories good?
Characteristics of a good User Story
INVEST – a popular mnemonic from Extreme Programming, an early agile methodology:
Where possible, a story should be:
Independent Negotiable Valuable Estimatable Small Testable
So, these are not rules
COMP3297: Software Engineering 2
Independent
As far as possible, stories should not overlap, should be self-contained, understandable and valuable in isolation, and able to be scheduled and implemented in any order.
Warning: many articles about User Stories, state this like a rule.
In real world development, it is impossible to make all stories independent and self-contained.
But really only need to avoid problematic dependencies.
Common theme throughout Software Engineering
COMP3297: Software Engineering 3
Independent
In agile, want to develop the most important, valuable stories first. Dependencies are a problem if they prevent that, forcing us to do less essential work first.
We’d like to be able to schedule and implement stories in any order.
Examples of dependencies:
Registration and authentication before the key operations related to a particular user role, like for a Clinic Manager.
Functions to add products to system before the functions to view and add them to orders
How can we avoid them?
COMP3297: Software Engineering 4
Independent
Theme: Search for supplies
Story: Search by name
Story: Search by manufacturer Story: Search by category Story: …
Theme: Manage Order
Story: Add item to order
Story: Remove item from order Story: Change item quantity Story: …
Is the “Themes” approach problematic? Containment dependencies? No, it is just a tool for organizing stories.
But what about the sequential dependencies within and between themes?
Maybe it’s the natural order for scheduling anyway!
COMP3297: Software Engineering 5
Independent: Violation
Can violate through containment dependency (“this epic/theme/story contains these others”) if you schedule to complete all of it before a dependent epic/theme/story can be started.
It’s rare that all the valuable stories are contained in the same theme.
As long as a product has the key functions so users can achieve their goals, it doesn’t need every function before you release an increment.
X
Keeping in mind the Minimum Viable Product (for learning), or
Minimum Marketable Product (for earning) will help.
COMP3297: Software Engineering 6
Negotiable – user stories aren’t contracts
This is a reminder to avoid the Waterfall approach of writing requirements in great detail at the start of a project and then treating them like contracts.
In agile, stories evolve through collaboration with stakeholders.
Keep stories at a high level and avoid unnecessary constraints. You’ll develop better solutions – but you’ll need to act on feedback.
COMP3297: Software Engineering 7
Negotiable: Violation
Common violation: over-constrain by specifying a solution rather than just the outcome of value.
As a clinic manager I want to see a carousel of images of supplies I order most frequently so that I don’t have to search for them every time.
Confirmation
• Ordering page shows image of each of 20 most frequently ordered supplies
• Each image shows for 5 seconds before being replaced by the next
• Manager can select an image to order that item
X
COMP3297: Software Engineering
8
Common examples: • Meet regulations,
Valuable
• Increase revenue,
• Avoid costs,
• Improve service,
• Build reputation,
• Create options,
• Generate information
Valuable to the end-user or customer.
Originally, this was a reminder not to work on, say, a horizontal layer, get it right, and then work on the next and integrate.
Value is in the effect of the system. And that happens at the edge. Valuable: Violation
Common violation: not actually delivering value to end-users
As a Hospital Authority warehouse admin, I want a database so that we can
store the current state of our inventory.
COMP3297: Software Engineering 9
Estimatable
Need not be precise. It is the exercise that is important to clarify the story and bring out hidden assumptions.
If a story is hard to estimate, then it is likely too large or too uncertain.
Estimatable: Violation
Common violation: not providing sufficient detail to estimate the work involved.
As a clinic manager I want to filter the catalog of supplies so that I can quickly find the item I want to order.
X
Unless details are in the Confirmation
COMP3297: Software Engineering
10
Technical uncertainty?
Spike.
Small
Go small while still delivering value – trend is hours to days of work, not weeks. Small can be developed fast since complexity is decreased.
Try for Minimum Useful Features (even Minimum Marketable Features may be too big).
Instead of starting big and decomposing, try starting smaller than you think and merge if necessary.
Small: Violation
Violations are clear: stories near the top of the Product Backlog must be sprintable. Can be easier to get there by starting small.
COMP3297: Software Engineering 11
Testable
“Don’t put stories into a sprint if they can’t get out.”
Testable: Violation
Common violation, especially for quality requirements: describing in vague, subjective terms.
Confirmation
• …fast
• …intuitive, easy to use, user-friendly • …robust
• …reliable
•…
X
COMP3297: Software Engineering
12
Writing Confirmations
Writing Confirmations
Saw previously:
Conditions of satisfaction that will confirm whether the delivered story does what is needed.
We add concrete detail to create the actual acceptance tests.
Two common formats:
as a checklist (the format shown earlier for the drone delivery system). as scenarios (Gherkin-like).
COMP3297: Software Engineering 14
Checklist (additional example):
As a clinic manager, I want to see previous orders I have tagged as “recurring” so that I can repeat an order without having to build it item by item.
Confirmation:
Option on Ordering page to view recurring orders.
See summaries of recurring orders showing items and quantities, sorted by frequency of selection, most frequent first.
Manager may select an order to be repeated as a new order
COMP3297: Software Engineering 15
Checklist (additional example):
As an airline customer, I want to be able to cancel my reservation.
Confirmation:
…
Cancelling more than 24 hours in advance gets a complete refund
Cancelling less than 24 hours in advance gets a complete refund less a $500 cancellation fee
A cancellation code is displayed and is provided to the customer by email as confirmation
… …
?
COMP3297: Software Engineering 16
Scenarios
Cucumber is a tool that:
“reads executable specifications written in plain text and validates that the software
does what those specifications say”
Cucumber specifications are written in a simple language called Gherkin
The approach is popular in agile development (it supports behavior-driven development).
It’s why you’ll often see Confirmations written using Gherkin-like syntax using a Given/When/Then template.
COMP3297: Software Engineering 17
Given/When/Then
Given Gives context for the behavior described by the story. Detail can be added later to provide specific context for
individual acceptance tests (see next slides).
The “givens” then become the preconditions – set-up – for running the test
When Action or event that triggers the behaviour
Then The expected effect. What the system must do in response to the “when” event.
COMP3297: Software Engineering 18
Scenarios
Something like this:
Say, for simplicity, supplies can only be ordered in quantities of one.
Add to Order: As a clinic manager I want to order an item I’ve selected.
Confirmation
Given I’ve selected an item
And the item is in stock
When I request to order it
Then the item is added to my current order
COMP3297: Software Engineering 19
Scenarios
Detail then added to turn the confirmation into executable acceptance tests:
Given I’ve selected item with ID 53075 And the stock level of item ID 53075 is 1 When I request to order it
Then my order contains item ID 53075
Given I’ve selected item with ID 53075 And the stock level of item ID 53075 is 0 When I request to order it
Then I see a message “Item not in stock” And my order is unchanged
To execute first test case:
Set these initial conditions Fire this action
Ensure this outcome
COMP3297: Software Engineering 20