User Stories 205IIT ACADEMY

User Stories and Acceptance Criteria

Industrie IT

contents• user stories - what/why/how • exercise • acceptance criteria - what/why/how • exercise

SCALING 204IIT ACADEMY

user storieswhat?

defineStories are a:

• User’s need • Product description • Planning item • Token for a conversation • Mechanism for deferring

conversation

SCALING 204IIT ACADEMY

*"Kent Beck coined the term user stories in Extreme Programming Explained 1st

Edition, 1999

a format

As a [user], I want [functionality] so that I can [benefit]

SCALING 204IIT ACADEMY

user storieswhy?

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 204IIT ACADEMY

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 204IIT ACADEMY

ACCEPTANCECRITERIA

FLOWS – SCREEN,DATA, LOGIC, ET AL.

ARCHITECTURE –DATA, INFRA, ET AL.

WIREFRAMES

USER STORY

UX

ARCH

DEV OPS

RELEASE

are “boundary objects”

boundary objects

SCALING 204IIT 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

user storieshow?

Eight keys to good user stories

SCALING 204IIT 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

1 Focus on the user

Use an actual role, not the word “user”. e.g. Marketing Admin, Broker, End customer, Head Office User.

SCALING 204IIT ACADEMY

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 204IIT ACADEMY

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 204IIT ACADEMY

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 204IIT ACADEMY

SCALING 204IIT 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

Recap - first four keys

SCALING 204IIT ACADEMY

1. Focus on the user

2. Facilitate a conversation

3. Story writing is teamwork

4. Simple and concise

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 204IIT ACADEMY

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 204IIT ACADEMY

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 204IIT ACADEMY

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 204IIT ACADEMY

Recap - last four keys

SCALING 204IIT ACADEMY

5. Decompose stories

6. Use acceptance criteria

7. User stories aren’t everything

8. Design vertical slices

user storiesexercise

SCALING 204IIT 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.

acceptance criteria

what

Acceptance Criteria RecapA 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 204IIT ACADEMY

acceptance criteria

why?

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 204IIT ACADEMY

What wasintended

What wascoded

What was tested

Because the usual documentation processes produce this:

documentation debt,source of defects,

wasted development effort

Because the usual documentation processes produce this:

What wasintended

What wascoded

What was tested

over-documentation, missed requirements, source of scope creep

Because the usual documentation processes produce this:

What wasintended

What wascoded

What was tested

wastedtestingeffort

Because the usual documentation processes produce this:

What wasintended

What wascoded

What was tested

Because the usual documentation processes produce this:

What wasintended

What wascoded

What was tested

documented, tested, purposeful code

documentation documentation

code

Development

Sprint Planning

Smoke Testing

Test Validation

Acceptance Testing

Acceptance Criteria/Test Approach

Product Management

PortfolioManagement

UsageExecutive 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

intention = code = test

federate intentions with what is both coded and tested

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)

PortfolioManagement

UsageExecutive 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

WIPUSER ACEPT

W/FUX

ARCH code

code

+

user stories + acceptance criteria support working, tested software

acceptance criteria

how?

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 204IIT ACADEMY

1. Pass/Fail

Each statement is pass/fail result. No “partial acceptance”

SCALING 204IIT ACADEMY

2. Bounds from Customer perspective

Defines expectations Clearly bounds the story in customer language

SCALING 204IIT ACADEMY

3. Actionable

SCALING 204IIT ACADEMY

Can be translated into one or more actionable test cases

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 204IIT ACADEMY

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 204IIT ACADEMY

example of usageThe 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 204IIT ACADEMY

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 204IIT ACADEMY

acceptance criteria

exercise

"As a web master, I can configure widget B to display in one of the three primary colors

of blue, red, and yellow"

SCALING 204IIT ACADEMY

example answerA 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 204IIT ACADEMY

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 204IIT ACADEMY