Presented at Macmillan Cancer Support in London on 26 April 2012

1. Macmillan Cancer Support, April 2012

2. What itch is there to scratch?
 Software requirements are a communication
problem
 People who want the
software must
communicate with
those who will build it

3. Balance is paramount
 If either side dominates, the business loses
 If the business side dominates ...
 ... functionality and dates are mandated with little
regard for reality or whether the developers understand
the requirements
 If the developers dominate ...
 ... technical jargon replaces the language of the business
and developers lose the opportunity to learn from
listening

4. Domination leads to ...
If developers are responsible ...
• May trade quality for additional features
• May only partially implement a feature
• May solely make decisions that should involve the
business side
If the business is responsible ...
• Lengthy upfont requirements negotiation and signoff
• Features are progressively dropped as deadline nears
• Features are continuously changed w/o
understanding of impact

5. Imperfect schedules
 We cannot perfectly predict a software
schedule
 As users see the software, they come up with new
ideas
 Too many intangibles
 Developers have a notoriously hard time estimating
 If we can’t perfectly predict a schedule, we
can’t perfectly say what will be delivered

6. So what do we do?
We make decision
based on the ... but do it often
information we have
Rather than making ... we spread decision-
one all-encompassing making across the
set of decisions project
This is were
I come in!

7. What are user stories?
Card
• Stories are traditionally written on note cards
• Cards may be annotated with estimates, notes, etc.
Conversation
• Details behind the story come out during
conversations with the product owner
Confirmation
• Acceptance tests confirm whether the story was
coded correctly

8. Anatomy of a user stories
As a <role>,
I want <action that needs to be achieved>
so that <goal the completed action achieves or contributes
to>.
Example:
As an individual fundraiser,
I want to be able to download the MacMillan logo
so that I can use it to print all my fundraising material in high
quality.

9. Stakeholder user stories
In order to <achieve some outcome which contributes to the
vision>
As a <stakeholder>
I want <some other stakeholder> <to do, use or be restricted
by something>
Example:
In order to be in a position to launch phase 1 of SSO
As the head of digital media
I want users to be able to login on Be.MacMillan using their
My.MacMillan credentials well.

10. Examples
As a user, I want As a photographer, I
want to see a preview
to order prints of of the photo book
my photos before I order
As a frequent flyer, I
As a user, I want to rebook a past
want to cancel trip so that I save
my order time booking trips I
take often

11. But ... where are the details?
 As a user, I want to cancel my order
 Does the user get a full or partial refund?
 Is the refund to user’s credit card or is it site credit?
 How far ahead must the or der be cancelled?
 Is that the same for all orders?
 For all customers? Different requirements by market?
 Is a confirmation provided to the user?
 On-screen? Email? Letter?

12. a) Details as conditions of satisfation
• The product owner’s conditions of satisfaction can be
added to a story
• These are essentially tests / acceptance criteria
As a user, I  Verify that a VIP member can cancel the same
day without a fee
want to cancel
 Verify that a non-VIP member is charged 10%
for a same-day cancellation
 Verify that any refunds are in site credits only
my order  Verify that an email confirmation is sent
 Verify that the factory is notified of any
cancellation

13. b) Details added in smaller sub-stories
As a VIP member, I
want to cancel an
order up to the last
As a user, I minute
want to cancel
my order As a non-VIP
member, I want to
cancel my order
within 24h of
placing

14. Techniques can be combined
 Both approaches are not mutually
exclusive
 Write stories at an appropriate level
 By the time it’s implemented, each
story will have conditions of
satisfaction associated with it

15. Product backlog pyramid
User
Stories Sprint
Theme
Collection of
Release related user
stories
Epic Future
A large user Releases
story

16. Exercise 1
 See how many user stories you can write about logging
in
Use this template
“As a <user role>, I wan <goal> so that <reason>.”
 Examples:
 As a registered user, I am required to log in so that I can
access the system
 As a forgetful user, I can request a password reminder to
that I can log in if I forget mine

17. Writing good stories
I ndependent
N egotiable
V aluable
E stimable
S mall / appropriately sized
T estable

18. Independent
As a user, I want As a user, I want
to pay for my to pay for my
order with VISA order with one
type of credit
card
As a user, I want to
As a user, I want
pay for my order with
to pay for my an additional type of
order with credit card
Mastercard

19. Negotiable
As a user, I want to pay for my

order with my credit card
Note: Accept Visa, MasterCard and American Express.
Consider Discover
As a user, I want to pay for my order

with my credit card
Note: Accept Visa, MasterCard and American Express. Consider Discover. On
purchases over £100, ask for card ID number from back of card. The system
can tell what type of card it is from the 1st two digits of the card number.
The system can store a card number for future use. Collect the expiration
month and date of the card

20. Why negotiable?
Main course comes with soup
or salad and bread
(Soup or Salad) and Bread
Soup or (Salad and Bread)

21. Estimable
 It is important for developers to be able to estimate or
at least take a guess at the size of a story
3 common failures
1. Developers lack technical knowledge
2. Developers lack domain knowledge
3. Story is too big

22. Small / Sized appropriately
2 kind of epics
1. Compound epic
2. Complex epic
Compound epic
• Comprises of multiple shorter stories
Complex epic
• Cannot be easily disaggregated into smaller stories
-> use spikes to find out how to split epics

23. Testable
A user must
find the
software easy 
to use
A user must never
have to wait long for
any screen to appear


24. Who writes them?
 The Product Owner!!!!
 Developers can help and write technical user stories if
needed
 However, ultimate responsibility lies with the PO
 The PO is also responsible for prioritisation of stories

25. Story-writing workshops
 Include the whole team plus the product owner and
possibly some more external stakeholders
 Typically not done every sprint
 Brainstorm to generate stories
 Goal is to write as many stories as possible
 Some will be “implementation ready”
 Others will be epics
 Start with epics and iterate
 NO PRIORITISATION at this point

26. Slicing Epics
 Goal: Develop slices of the problem that produces
valuable working software with the potential to
generate feedback from users.
 Sometimes the story slices are not deliverable to end-
users but they generate value from the learning gained
in producing them.
 They should all result in testable and demonstrable
software.

27. Slicing considerations
 DTSTTCPW principle (=Do The Simplest Thing That
Could Possibly Work)
 What are the different ways that you can handle
input/output data ?
• You can make a story per input screen.
• You can make a story per enabled elements of an input
screen.
• You can make a simple (not pretty) UI prototype.
 What scenarios are in scope for acceptance criteria?
• You can work with a subset of the input data.
• You can defer conditional steps to other stories.
• You can defer data validation.
• You can defer error handling.

28. Slicing considerations
 What architecture decisions can be deferred?
• You can defer optimisation of performance.
• You can defer internationalisation
• You can defer handling large volumes of data
 Worklow steps
 Performance
 Spikes
 Quality
 Things you know / don’t know

29. Horizontal slicing & sizing
 Try not to slice stories along technical lines
 Slice them horizontally for as long as you possibly can
 1) Exercising every layer reduces risk of finding last minute
problems in one of the layers
 2) Application with reduced functionality can still be
released
 Example: “A job user can post a CV” (epic)
-> “A job seeker can fill out a CV form”
-> “Information on a resume form is written to the db”
Correct:
-> “A job seeker can submit a CV that includes only basic information such as
name, address and work history”
-> “A job seeker can submit a CV with all information an employer may want to
see”

30. Real world example

31. Exercise 2 Remember:
1. Who writes user stories?
 Employees can purchase 2. User role
parking passes 3. User story format
4. Aim / goal / business value

As an employee I want to Buyer is charged fee for 1 month only time
 One pass for one month is issues at a
purchase a parking pass No pass is issued if payment is insufficient


so that I can drive to work Buyer must be can only buy one pass per
a current employee
 Any employee
month

32. Exercise 3 Remember:
1. Who writes user stories?
 Users can sort cards by 2. User role
popularity 3. User story format
4. Aim / goal / business value
 User can sort by most popular 1st
As a customer I want to  Timeframe for popularity is last 2
sort available cards by weeks
popularity so that I can  Sorting mechanism works will all filters
easily access the  Sorting takes no longer than 2 seconds
bestsellers  User can un-sort without losing applied
filters

33. Non-functional requirements
 For some requirements it’s inefficient to be captured in
user stories because they apply to all of them
 Example 1: “The system must support peak usage of up
to 50 concurrent users”
 Example 2: “Do not make it hard to i18n the software
later if needed”
Constraint
 Write constraint cards and
The software must
keep them visible run on all versions of
Windows 2k +

34. Closed stories
 When breaking down stories aim for closed stories
 Closed stories end with the achievement of a
meaningful goal
 Example: “A user can reprint previous orders”

35. Keep UI out as long as possible
 Agile is about conversations and discussions
 Eventually inevitable
 Keep stories with UI elements until a later sprint when
stories shift from being new functionality to being
modification of existing functionality
 Example: “A user can select dates from a date widget
on the search screen”

36. This smells
 Too many interdependent stories -> make stories
larger or slice them differently
 Goldplating -> increase visibility of tasks & workload
 Too many details -> if you run out of room, use smaller
cards
 Thinking too far ahead -> stop
 Splitting too many stories
 PO can’t prioritise -> close look at value

37. Recognising smells
 Developer responsibilities
You share a responsibility with the PO to be aware of
these smells as well as any others you may detect.
Work and correct any that affect the project
 PO responsibilities
You share a responsibility with the PO to be aware of
these smells as well as any others you may detect.
Work and correct any that affect the project