The aim of this workshop is to get people aware of the complexity of software development.
This is a relatively simple object that most people will have come across in day-to-day life. It has a single well understood purpose.
This is a more complex object
This is a one-of-a-kind object. Much of what we&#x2019;re building in software development is unique. The language that we use to describe this thing is therefore inexact and open to interpretation.
The aim of this is to illustrate how much better vocal communication is over documentation. Have the participants vote as to which it is, and then pick one to emphasize when you say the sentence.
This next 2 slides illustrate the importance of communicating the intention of the user and not just the solution description. Remember that most people rarely read the whole requirements doc
So this is where user stories come in
It&#x2019;s important to note that in total, you should only have 35-50 items in your backlog at any one time. There should be a steady flow of epics to features to stories
By the time it comes to implement epics, we might have changed out minds based on what we&#x2019;ve already built. Therefore don&#x2019;t invest the time to define them more clearly until you&#x2019;re ready to build them
The mantra here is &#x2018;Just Enough, Just In Time&#x2019;
This format was the product of Mike Cohn&#x2019;s work.
Ron Jeffries and his work in Xtreme Programming is credited with the idea behind this formulation.
We use acceptance tests to help us understand how the story should be implemented. They supply the details that the team needs.
This exercise is meant to illustrate the importance of asking questions of the customer / user. The trick is when the team has sorted the bag of mixed coins by denominations you tell them you actually wanted it by date.
Stresses the importance of not closing off avenues to explore with the users.
Techniques for helping you talk to your customers.
The story here is that in pitching a product at an extreme users (the elderly) OXO actually ended up with a better overall design of a potato peeler that appealed to everyone. Your extreme users can help you find ways in which people use your products that might not have occurred to you.
Bill Wakefield is credited with this acronym for the test of what constitutes a good user story. Think of this as a checklist when you are story writing.
The important part here is to make sure that your acceptance criteria are defined. Note: you may have multiple constraints for a particular type (e.g. batch vs real-time performance)
This idea is stolen from Roman Pinchler&#x2019;s book.
Remember to at least try writing it as a user story first...
Writing Effective User Stories
Writing Effective User stories
Presented by Carlo Kruger
What were they thinking?
•Split into teams, with one product owner
•Product owners may only communicate with the team
through imperatives (“it must have/do...”) or similes (“it’s
•Cannot use the name of the thing in a sentence (“it must
pour tea” for a teapot is not allowed)
•Teams cannot ask questions
•Teams have 2 minutes to draw the object seen by the PO
The system must store an address and business phone or mobile phone
1 Address +
(business phone or
(Address + business
phone) or mobile
Dude, where’s my car?
•Have a gas engine
•Rubber tire on each wheel
•Has a steering wheel
•Has a steel body
Focus on intention
•As a user I want to
mow my lawn quickly
•As a user I want to
be comfortable while
mowing my lawn
So now what?
We make decisions based
...but we do it often
on the info we have
Rather than make one in ...we spread decision-
set of all-encompassing making across the
The Product Backlog iceberg
1-2 sprints worth of stories Stories
y a ress
Id xp ies!
e e or
ti ll b r s t
a su se Epics /
What are epics?
•Large fuzzy requirements
•May consist of a number of features
What’s a feature?
•A set of requirements which can be grouped
•which deliver value to a group of users
What are user stories?
As a: <user role or persona>
I want to: <do something, a piece of functionality>
So that: <achieve some business value or statement of intent>
The 3 C’s
•Stories are traditionally
written on note cards
•Cards may be annotated
with estimates, tests, etc
•Details of story come out
Conversation during conversations
with product owner
•Acceptance tests conﬁrm
Conﬁrmation the story was coded
But what about the details?
•As a user I want to be able to cancel a reservation so
that I can get a refund for the trip not taken
• Does the user get a full or partial refund?
• Is the refund to the credit card or is it a site refund?
• How far ahead must the reservation be cancelled?
• Is it the same for all hotels?
• How about all site visitors? Can frequent travellers cancel later?
• Is a conﬁrmation provided to the user?
• How do provide this conﬁrmation?
Given: it is 2 weeks till my ﬂight and I paid $1000 for
the ﬂight and I am not a frequent traveler
When: I cancel my ﬂight
Then: I get a 50% refund ($500) and my ﬂight is
•Describes starting state, event and ﬁnal state
•Use ‘real’ examples with meaningful values
The Happy Path
•Every story should deﬁne the default scenario
•similar to happy path in a use case
•extend with negative scenarios and edge cases
How long will it take to sort this bag of coins?
Talking to users
•Ask open ended questions
•closed = “Yes or No”
•open = “What would you be willing to trade for
•Give user options (“This one or that one?”)
Story writing with your
•Low ﬁdelity prototypes to get the main ﬂows
•Get breadth ﬁrst
•Use user roles / personas to help identify missing
•Compare against competing products
•allow users to vary by
•what they use the software for
•how they use the software
•familiarity with software / computers
• Every product has more than one type of user
• when we write with only one perspective
• we assume all users have the same goal
• leads to missing stories
What makes a good story?
• Dependencies lead to prioritisation problems
• Stories are not contracts
• leave the team room to manoeuvre
• to users or customers (rarely if ever developers)
• try to rewrite developer stories to reﬂect value to the customer
• we plan using user stories so we must be able to estimate them
•Small (sized appropriately)
• Compound stories are multiple stories
• Complex stories are intrinsically large
• if you can’t test it, how do you know when you’re done?
What makes a good user story?
•It describes what a user does
•Explicitly states dependencies
•Takes a slice through the system
•Ends with a meaningful goal
• instead of “a home seeker can maintain her search criteria”
• a home seeker can create her search criteria
• a home seeker can review the results of a search
• a home seeker can change the geographic area of a search
“...is a requirement that speciﬁes criteria that can be used to judge the operation of a
system, rather than speciﬁc behaviours” - Wikipedia
Formulate NFR’s as a story
•10,000 concurrent R/W
transactions take place
The system must answer any
request in less than 1 second
•Each transaction is 500Kb
•System conﬁg is ‘small
Linking to functional
Theme Functional requirement Performance Security Robustness
As an enterprise user, I want to select a
Emailing recipient from my contact list, so that I can X X
get the correct address
• Adding CI, optimising DB, upgrade to latest Oracle, etc.
• Consider trying to write a user story so that you are forced to deﬁne the business value
• No user facing functionality, e.g. Rating engine consumes some
• Consider writing as a user story with the engine as the user
• e.g: As the rating engine, I want well formed CDR’s so that I can minimise
• Don’t hurt yourself trying to force it; sometimes it’s OK not to use the format
• Be careful that these aren’t tasks that have been elevated to stories...
Decomposing user stories
• Compound Stories
• a number of smaller stories / scenarios
• split into meaningful chunks
• Complex Stories
• if it’s largely unknown, consider a spike
• try ﬁnd ‘natural’ seams in the story
• Combining stories
• stories should be about 2 days work
• if too small combine e.g. bugs into one story
Patterns for splitting stories
• Workﬂow steps
• Business rule variations
• Major / Minor effort
• Simple / Complex
• Variations in available data
• Data entry methods
• Defer performance
• Operations (e.g. create / update / delete)
When do I write stories?
•5-10% of total team effort should be spent on
preparing for the next sprint
•i.e. about 50% of analyst’s time in sprint
•still need to be available to team (should be
answering 80% of queries in <10min)
•estimation meetings in off-week
Story writing workshops
•Include team, users, customers
•Brainstorm to generate ideas
•Write as many as possible
•Start with epics and iterate
•or use mindmaps
paid tick rrest eds its
I f th
hen a If a warran rt
Cops & Fines
E ach p
port of o
be is s en th rrest
issue d, th
st is the a The viola
arr e ed of be set tion mus
t be i nform e can master l
ist of ve
t be link
e d to a
mus ria l dat Our officers now carry GPS units, so the hicles. W
so th at a t co-ordinates of the offence must be
cle manu e also n
type (se facturer ee d
logged on the ticket. The officer will dan, SUV , colo ur,
It wo reg istrat , etc) an
login to the mobile app using their ion d
phot e so badge number and password
of th ph o if the
e vio r vid
show latio eo cl
n on n cou ip
a Go ld be
ogle We would like to ‘name and
shame’ top offenders on our
ofﬁcer FaceBook page automatically,
nnual bo nus of an
The a ber of on the 1st of each month
is linke d to the nu m
s that h ave been
n d pai d
Credit & thanks to Aslam Khan for the stories
issue d a
•Too small or too big
•Estimates don’t converge
•No scenarios / acceptance criteria
•Thinking too far ahead
•Splitting too frequently
Use cases vs. user stories
•User stories much smaller than use cases
•use cases are exhaustive, user stories much less detail
•use cases intended as permanent record, user stories
rarely last beyond the sprint
•Mike Cohn - ‘User Stories Applied’
•Lefﬁngwell & Behrens - ‘A User Story Primer’
•Victoria Hall - ‘Crafting Better Scrum Requirements’
•Mike Cohn - ‘An introduction to user stories’
•Roman Pinchler - ‘Agile Product Management with