IIT Academy: Agile. Learn how to articulate customer expectations and build precisely what was intended, with the minimum of traceability issues. Acceptance Criteria (in conjunction with good agile practices) is a way to create well documented, high-quality codebase tested using the same set of standards by developers, testers, analysts, designers as well as the Product Owner. Learn good Acceptance Criteria - the keys to customer success in agile delivery!

1. User Stories 205
IIT ACADEMY
User Stories and
Acceptance Criteria
Industrie IT

2. contents
• user stories - what/why/how
• exercise
• acceptance criteria - what/why/how
• exercise
SCALING 204
IIT ACADEMY

3. user stories
what?

4. define
Stories are a:
• User’s need
• Product description
• Planning item
• Token for a conversation
• Mechanism for deferring
conversation
SCALING 204
IIT ACADEMY
*"Kent Beck coined the
term user stories in Extreme
Programming Explained 1st
Edition, 1999

5. a format
As a [user], I want [functionality]
so that I can [benefit]
SCALING 204
IIT ACADEMY

6. user stories
why?

7. advantages
• Easy-to-write
• Easy-to-understand
• User-centric
• Easily understood by customer and technical
• End-to-end functionality
• Facilitates conversations
• Can be sized
• Is goal-centric (abstracts out detail)
SCALING 204
IIT ACADEMY

8. WORKSHOPS
usage
• basic unit of functionality
• gain detail over time
• adds value to the product
• vertical slice through the product
• summarised as:
• “As a <type of user> I want <some goal>
so that <some reason>”
• has acceptance criteria
• can be used to capture non-functional requirements
• can be a spike
• may include wireframes, solution details etc.
SCALING 204
IIT ACADEMY
ACCEPTANCE
CRITERIA
FLOWS – SCREEN,
DATA, LOGIC, ET AL.
ARCHITECTURE –
DATA, INFRA, ET AL.
WIREFRAMES
USER STORY
UX
ARCH
DEV OPS
RELEASE
are “boundary objects”

9. boundary objects
SCALING 204
IIT ACADEMY
“A boundary object is a concept in sociology to describe
information used in different ways by different communities. They
are plastic, interpreted differently across communities but with
enough immutable content to maintain integrity” --Wikipedia
“They are weakly structured in common use, and become
strongly structured in individual-site use. They may be abstract
or concrete. They have different meanings in different social
worlds but their structure is common enough to more than one
world to make them recognizable means of translation. The
creation and management of boundary objects is key in
developing and maintaining coherence across intersecting social
worlds.” -- Leigh & Griesemer

10. user stories
how?

11. Eight keys to good user stories
SCALING 204
IIT ACADEMY
1. Focus on the user
2. Facilitate a conversation
3. Story writing is teamwork
4. Simple and concise
5. Decompose stories
6. Use acceptance criteria
7. User stories aren’t everything
8. Design vertical slices

12. 1 Focus on the user
Use an actual role, not the word “user”.
e.g. Marketing Admin, Broker, End
customer, Head Office User.
SCALING 204
IIT ACADEMY

13. 2 Facilitate a Conversation
A story is not a specification.
It is not a contract.
It does not replace dialogue.
It captures the essence of the conversation
into the essential elements.
SCALING 204
IIT ACADEMY

14. 3 Story Writing is Teamwork!
Change is the only constant. Rely on the wisdom and expertise of
the group to contribute perspectives, up-to-date information,
expertise.
Three pillars
• Visibility/Transparency
• Inspection
• Adaptation
SCALING 204
IIT ACADEMY

15. 4 Simple and Concise
As a user, I want to sign in and connect the database
to the mail API and view the email screen, so that I
can view all the emails that belong to me.
Exercise – 1 minute. Come up with a better one.
SCALING 204
IIT ACADEMY

16. SCALING 204
IIT ACADEMY
Example of a concise and simple user story:
• JIRA Name = “Email: View”
• User Story: “As an authenticated user, I want to view my emails.”
• Followed by detailed acceptance criteria
4 Simple and Concise

17. Recap - first four keys
SCALING 204
IIT ACADEMY
1. Focus on the user
2. Facilitate a conversation
3. Story writing is teamwork
4. Simple and concise

18. 5 Decompose Stories
Start with goals – can be as big as “do marketing”.
Break down into large stories 13-100 points. Contains user-
centric benefits.
Break large stories into small stories 1-8 points. Contains
incremental benefits.
SCALING 204
IIT ACADEMY

19. 6 Use Acceptance Criteria
Acceptance Criteria ensure testability. More on this
later.
E.g.
Scenario 1: Account balance is negative
Given the account’s balance is below 0
And there is not a scheduled direct deposit that day
When the account owner attempts to withdraw money
Then the bank will deny it
And send the account owner a nasty letter.
SCALING 204
IIT ACADEMY

20. 7 User Stories aren’t everything
Some things aren’t user stories, but should be included.
e.g. mockups, screenshots, seed data, relevant code snippets
Some things definitely are user stories:
Non-functional requirements should always be able to be expressed as user
stories and/or acceptance criteria.
E.g. As a broker, I want all buttons to respond to clicks in less than two
seconds.
Acceptance Criteria:
Measure time between clicks and responses
200 users active on website, no other functions performed at the same time.
SCALING 204
IIT ACADEMY

21. 8 Design Vertical Slices
A story contains everything
that it needs to in order to
deliver the benefit.
It delivers the minimum viable
product as soon as possible.
SCALING 204
IIT ACADEMY

22. Recap - last four keys
SCALING 204
IIT ACADEMY
5. Decompose stories
6. Use acceptance criteria
7. User stories aren’t everything
8. Design vertical slices

23. user stories
exercise

24. SCALING 204
IIT ACADEMY
Exercise: Restaurant App
Exercise: Write user stories for “A mobile app that
helps hungry diners find an appropriate place to eat”
Directions: Break into teams of 3-4 and discuss some
of the stories. Aim to create a vertical slice.
Directions: Arrange the subsequent stories into a user
experience order; and present them to the group.

25. acceptance
criteria
what

26. Acceptance Criteria Recap
A pass/fail set of criteria that the user story must meet
in order to be considered done.
“Conditions that a software product must satisfy to be
accepted by a user, customer or other stakeholder.”
- Microsoft
“Pre-established standards or requirements a product
or project must meet.”
- Google
SCALING 204
IIT ACADEMY

27. acceptance
criteria
why?

28. Why Acceptance Criteria?
Good Acceptance Criteria will help get your Agile
project from “It Works as Coded” to “It Works as
Intended.”
• Once work is complete, clients have no problem defining
what’s wrong.
• Acceptance Criteria is about clear communication about
intentions.
• Inaccurate or missing acceptance criteria can lead to low
customer satisfaction levels, missed delivery dates, and
development cost overruns. This is why it’s so critical to
accurately define them before any work begins.
SCALING 204
IIT ACADEMY

29. What was
intended
What was
coded
What was
tested
Because the usual documentation
processes produce this:

30. documentation debt,
source of defects,
wasted development effort
Because the usual documentation
processes produce this:
What was
intended
What was
coded
What was
tested

31. over-documentation,
missed requirements,
source of scope creep
Because the usual documentation
processes produce this:
What was
intended
What was
coded
What was
tested

32. wasted
testing
effort
Because the usual documentation
processes produce this:
What was
intended
What was
coded
What was
tested

33. Because the usual documentation
processes produce this:
What was
intended
What was
coded
What was
tested
documented, tested,
purposeful code

34. documentation documentation
code
Development
Sprint Planning
Smoke Testing
Test Validation
Acceptance Testing
Acceptance Criteria/
Test Approach
Product
Management
Portfolio
Management
Usage
Executive Stakeholders + End Users
Product Owners + Product Stakeholders
Developers
Functional Testing
Product Owners
Scrum Team
Business Cases (Backlog Epics)
Backlog + Wiki Structure
Sprint Backlog +
Wiki User Stories
User Story:
Testing Sections
User Story:
Technical Sections
User Story:
Delivery Decision Log
User Story > JIRA link:
Known Bugs/Issues
Update Sprint User Stories >
System Documentation
System Documentation: User Guides
Requests for changes, new scope, etc.
code
documentation supports code

35. intention = code = test
federate intentions with what is both coded
and tested

36. Development
Sprint Planning
(detailed US + some AC)
Smoke Testing
(against AC)
Test Validation
(validate AC)
Acceptance Testing
(against AC)
Acceptance Criteria
Product
Management
(high level US)
Portfolio
Management
Usage
Executive Stakeholders + End Users
Product Owners + Product Stakeholders
Developers
Functional Testing
(against AC)
Product Owners
Scrum Team
Business Cases (Backlog Epics)
Backlog + Wiki Structure
Sprint Backlog +
Wiki User Stories
User Story:
Testing Sections
User Story:
Technical Sections
User Story:
Delivery Decision Log
User Story > JIRA link:
Known Bugs/Issues
Update Sprint User Stories >
System Documentation
System Documentation: User Guides
Requests for changes, new scope, etc.
USER
WIPWIP
WIP
USER ACEPT
W/FUX
ARCH code
code
+
user stories + acceptance criteria support
working, tested software

37. acceptance
criteria
how?

38. Five Characteristics of good acceptance criteria
1. Each statement is pass/fail.
2. Bounds the story from customer perspective
3. Actionable
4. High level: does not re-hash requirements
5. State intent, but not dictate the solution
SCALING 204
IIT ACADEMY

39. 1. Pass/Fail
Each statement is pass/fail result.
No “partial acceptance”
SCALING 204
IIT ACADEMY

40. 2. Bounds from Customer perspective
Defines expectations
Clearly bounds the story in customer
language
SCALING 204
IIT ACADEMY

41. 3. Actionable
SCALING 204
IIT ACADEMY
Can be translated into one or more actionable test cases

42. 4. High Level
Does not re-hash requirements of story
• Contains functional requirements
(e.g. minimum viable product)
• Contains non-functional requirements
(e.g. minimal quality)
SCALING 204
IIT ACADEMY

43. 5. State intent, not solution
The criteria is independent of implementation.
“A manager can approve or disapprove an
audit form”
vs.
“A manager can click an ‘Approve/
Disapprove’ radio button to approve an audit
form”
SCALING 204
IIT ACADEMY

44. example of usage
The user story is presented, and the conversation starts.
For example:
As a conference attendee, I want to be able to register online, so I can
register quickly and cut down on paperwork
Questions for the Product Owner might include:
• What information needs to be collected to allow a user to register?
• Where does this information need to be collected/delivered?
• Can the user pay online as part of the registration process?
• Does the user need to be sent an acknowledgment?
The issues and ideas raised in this Q and A session are captured in the
story’s acceptance criteria.
SCALING 204
IIT ACADEMY

45. Acceptance Criteria
1. A user cannot submit a form without completing all the mandatory fields
2. Information from the form is stored in the registrations database
3. Protection against spam is working
4. Payment can be made via credit card
5. An acknowledgment email is sent to the user after submitting the form.
When the development team has finished working on the user story they
demonstrate the functionality to the Product Owner, showing how each criterion is
satisfied.
SCALING 204
IIT ACADEMY

46. acceptance
criteria
exercise

47. "As a web master, I can configure widget B
to display in one of the three primary colors
of blue, red, and yellow"
SCALING 204
IIT ACADEMY

48. example answer
A set of acceptance tests would be:
• The web master has access to the configuration options for widget B
• The web master has a selection list available of the three primary
colors of blue, red and yellow
• When the web master sets widget B to blue, it displays in blue
• When the web master sets widget B to red, it displays in red
• When the web master sets widget B to yellow, it displays in yellow
• The web master has no other options other than blue, red or yellow
SCALING 204
IIT ACADEMY

49. Additional User Stories
If, in writing the AC, we discover that we
need to ensure no-one else can access the
same options, we can add a new story to
say:
"As a web user, I do not have access to
widget B's configuration options"
And then write appropriate acceptance
criteria for that.
SCALING 204
IIT ACADEMY