+

Story RefinementHow to write and refine your stories

so that your team can reach DONE

by the end of your sprint!

Tonya McCaulley

Director of Training

ROME Agile

+About Your Speaker…

Born here

Raised here

Live here

Travel the world doing what I

love

Want to bring Ohio forward!

Tonya McCaulley

+Audience Poll

How many of you hit DONE by

the end of the sprint?

How many of you are using

Agile at work?

Why or why not?

+User Story and Acceptance

Criteria Refinement and hitting

DONE!

Level set on User Story

purpose and definitions

How to INVEST in good user

stories

Refining the Acceptance

Criteria. Beginning to end to

set your team up for

SUCCESS!!!

+

Let’s level-set on User

Story purpose and

definitions

+

Why user stories?

Keep yourself expressing business

value

Avoid introducing detail too early that

would prevent design options and

inappropriately lock developers into

one solution

Get to small enough chunks that invite

negotiation and movement in the

backlog

(MR./MRS. PO- THIS IS FOR YOU!!!)

Leave the technical functions to the

architect, developers, testers, etc.

+What is a User Story?

A concise, written description

of a piece of functionality

that will be valuable to a user

(or owner) of the software.

+User Story Description

Who (user role)

What (goal)

Why (value)

gives clarity as to why a feature is useful

can influence how a feature should function

can give you ideas for other useful features

that support the user's goals

+User Story Description

As a [user role] I want to [goal]

so I can [value]

For example:

• As a registered user I want to log in

so I can access subscriber-only content

+Use specific user roles

Try to avoid the generic role "User" when writing user stories.

User stories are about all of the "actors" who interact with the system or who realize some value or benefit from the system.

Not all actors are end users.

For example, an actor could be another system or someone who wants certain functionality in order to buy your product but will never actually use the product. It may be useful to create aggregate actors (e.g. "consumer") and specialized actors (e.g. "browser" or "frequent shopper").

These aggregates are called user personae.

+How big a piece of work should a user

story be?

User Story should be small enough to be coded and tested

within a sprint - ideally just a few days.

When a story is too large, it is called an "epic". Backlog items

tend to start as epics, when they are lower priority.

For release refinement & planning, epics should be broken

down into smaller chunks, but not so small that you've moved

into detailed design.

+Who can make a user story

Creation — The customer, customer proxy, product owner

and anyone else who identifies a need for the product can

contribute user stories.

Ownership & Maintenance — The product owner owns the

user stories and is responsible for writing, gathering,

maintaining, and prioritizing.

Usage — Developers, testers, technical writers use user

stories to be able to know what to implement and when

they're done. Product owners track overall progress based on

the status of the user stories. Management tends to track user

stories rolled up to epics or features.

INVEST in Good User Stories

User Stories should have these characteristics:

Independent – User Stories should be as independent as possible.

Negotiable – User Stories are not a contract. They are not detailed specifications. They

are reminders of features for the team to discuss and collaborate to clarify the details

near the time of development.

Valuable – User Stories should be valuable to the user (or owner) of the solution. They

should be written in user language. They should be features, not tasks.

Estimatable – User Stories need to be possible to estimate. They need to provide

enough information to estimate, without being too detailed.

Small – User Stories should be small. Not too small. But not too big.

Testable – User Stories need to be worded in a way that is testable, i.e. not too

subjective and to provide clear details of how the User Story will be tested.

+

Acceptance Criteria

Refinement Start

The ASK is input in “Execution”

state get and may get

automatically converted

depending on software used

Three Amigos

PO, Architect, UX/QA

Refinement Team

Features are presented

to assign the three

amigos in charge of

refining them.

Three Amigos

• Create the Epics

• Identify Scenarios

• Identify solution and document

it inside the Epics

Next step: Estimation

Project: Backlog

Estimation: 20% to 50% confidence

Three Amigos

Once there is agreement on 1

piece of Acceptance criteria and

scenarios for a US, an estimate is

provided for it [1]. The estimate is

at 20% confidence level if it is

above 13 SP (the reference value

for something feasible within 1

sprint) and if the story cannot get

assigned to one specific team.

[1] Estimates are provided in SP using Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, …). At 20% confidence level, the estimate can be

expressed also in T-Shirt size (XS to XL) with the following correspondence: S <= 13, M = 21, L= 34, XL = 55, XXL = 89, XXXL = 144)

Estimate <= 13 SP and

US assigned to one scrum team?

YESThree Amigos

US break down (by scenario)

Prioritize broken down US

Identify acceptance criteria

Estimate

NO

Beyond scope

Estimation: 50% to 80% confidence (and beyond)

Scrum team (look ahead meeting)

• Revisit data at the right time (i.e.

when the 80% bucket depletes) to

refine available information.

• Add test scenarios

(Further breakdown possible, at

scrum team level) Scrum Team (Iteration

planning meeting)

Entry point for

Release and Iteration

planning

The confidence buckets

New Feature-

3 amigos team is identifiedEpic are created, discussed

and estimatedUS are broken down to fit

Single scrum teams and

and single iterations

(SP<=13)

Information is refined to

be ready for sprint

planning

These buckets correspond to backlog portions to be constantly kept filled up (i.e. with 2-3 iterations worth of work in

every bucket at any time)

To executionSome 3 amigos teams work

on this transition

In parallel, some other 3

amigos teams work on this

transition

In parallel, Scrum teams

work on this transition as

part of the look ahead

meetings

WW I

W WeeklyFrequency

guidelines:

I Every

iteration

Can AC any day!

80%

50%

20%

2-3 iterations worth of work

2-3 iterations worth of work

2-3 iterations worth of work

Constantly, 9

iterations worth of

work are stack-

ranked and estimated

(at different level of

confidence). We can

take a snapshot of this

to use for a

commitment every

day.

+Let’s do some laundry!

How many

tasks does it

take you to

finish your

laundry?

What did we learn?

Make sure you ask the right questions of your PO

Ask WHO (role) is using it.

WHAT they are using (goal) and

WHY (Value).

User Story Acceptance Criteria

• In addition to the statement of the user story, additional notes, assumptions, and acceptance criteria can be kept with a user story on your scrum board or electronic scrum board (there is a separate section for Acceptance Criteria).

• Many discussions about a story between the team and customers will likely take place before and during the time the story is committed to code.

**NOTE: One of the GREAT things about AGILE is CREATIVE LICENSE and being RESULTS DRIVEN. ∫ The difference between Design and Acceptance Criteria is what you ask about and your customer cares about.

+Acceptance Criteria for

Confirmation

Represents the items that the PO will verify

in order to confirm that a story is done.

Gives the team the detail necessary to

delimit the product and correctly size the

story.

Scenarios are excellent ways to delimit the

product.

The team will build the simplest solution to

the acceptance criteria; if you care about

something, communicate it to the team.

Any scenarios that are not included in a

story, but need to be completed are put on

another card & added to the backlog.

Gherkin is Workin’

Use Gherkin format when writing Acceptance Criteria

Given: State of the system BEFORE user action takes place

When: User action

Then: State of system AFTER user action takes place

EXAMPLE

GIVEN: no display of state of services or components

WHEN: I choose to monitor /display dashboard of service availability

THEN: I should see the Green dot representing site up and running

Setting Your Team Up For Success

is a WIN WIN For Everyone!

Get it DONE!