agile training - user stories and backlog

8/12/2019 Agile Training - User Stories and Backlog

1/12

gile TrainingAgile Product Backlog and Stories

For Internal Use Only


2/12

Agile Process Overview

Retrospective

Deliverable*

Product

Backlog

Release

Backlog

Iteration

Backlog

2 to 4 Weeks

24 hours

Iteration Planning

Tasks defined /

expanded

by team

Daily Stand-up

Meeting

VisionJan May Aug Dec

Product Roadmap

Prioritization

* Demonstrable, working

system

Inspect

Adapt

Update Backlog as needed

Features

Epics

Stories

Stories

2

Iteration


3/12

Product Backlog

The Product Backlog is the master l is t of all func t ionali tydesired in the p rodu ct, that evolves i terat ively throughout

the entire pro ject.

Product Backlog items, referred to as Stories, are typically user-centric, hence

the term User Stories, but will also include technical and other non-functionalstories that will need to be developed and delivered.

The on-going process of iteratively maintaining the Backlog is referred to as

Grooming.

As the Project and Backlog evolves, the Product Owner and the Team willcollaborate to groom, order and size the Stories. Backlog Order starts with

Business Priority/Value, and is then refined based on Risk, Necessity, and any

logical or technical dependencies.

The Product Owner(s), with the assistance of BAs and/or SMEs, are responsible

for writing the Stories, based on the desired functionality.3


4/12

The Lifecycle of a Story

Tasks

Build UI

Setup DB

Update Front-End

Build Web Service

Update Tech Design

DB Testing

Front-End Testing

Iteration Planning

Beginning of each

Iteration

Acceptance Criteria

Able to add a book to

the shopping cart from the

Search page

Able to add a book to

the shopping cart from a

books detail page

Able to see the books

added to my shopping cart

as well as the quantity

Backlog Grooming

On-going, prior to

Iteration planning

(just in time)

Story (Narrative)

As a user, I want to

be able to add books

to my shopping cart

so that I can buy them

Story Discovery

On-going, looking

ahead 1-2 iterations,

planned Release4


5/12

5

Release

Theme 1

Theme 2Theme

n

Theme

Epic 1

Epic 2

Epic n

Epic 1(aka. Feature)

Story 1

Story 2

Story n

Story 1

Task 1

Task 2

Task n

Task 1

Maintain an iterative process of analysis to continually refine and

decompose Requirements into discrete units of work

Level of Effort (LOE) estimates are iteratively refined as decomposition

reveals new information (gaps, complexities, redundancies, etc)

Process Level 1 / 2*i.e. work stream and/or core functionality

Blueprint Document leveli.e. BPxxx_Standard_Order_Process

Detailed Requirement /

Process Step leveli.e. Create Standard Order

Unit of Worki.e. BPxxx_B_001

*May be a Business

Requirement,

RICEFW,

Configuration, etc

Process Level 2i.e. Sales Order Process

Requirements / Backlog Decomposition*SAP example


6/12

What is a Story?

The User Story represents customerrequirements rather than documentsthem

Provides a simple format to insure consistent,

correct communications with the team and

stakeholders

Serves as a Token for a conversation

Feature descriptions from the perspective of theUser/Customer

Also includes requirements of System or the

team - these are referred to as non-

functional stories

Includes "Acceptance Criteria, which are clearly

defined conditions, that can be tested anddemonstrated, required to be met in order for

the Product Owner to accept it

Able be completed as a distinct deliverable,

within a single iteration, independent of other

stories

Format of a User Story:

As a,

I need to ,

So that

As a customer service rep ,

I need to cancel an order, at thecustomers request,

so that I can provide quality

customer service.

As a System,I need to Map Master Data

changes, so that I can enable

Sales Order Processing steps.

6

User stories are increasingly used on Agile projects. This popularity is a very good thing. Goal and business oriented,

their simplicity and a immediate focus on acceptance criteriamake them terribly effective on design projects.


7/12

INVEST in quality Stories

Independent

Negotiable

Valuable

Estimable

Small

Testable

I

E

N

S

T

V

IndependentWrite closed, self-contained StoriesAble be completed as a distinct deliverable

Vertically slice through the architecture and/or functionalityNegotiable

Not contracts or detailed requirementsToo much detail gives impression of false precision orcompleteness

Flexibility drives release schedule and goalsValuable (to Users/Customers)

Write stories in the voice of the customerWrite from perspective of a single User, if applicable

EstimableStories are for planning and trackingRequires domain knowledge and expertise on the teamCant be too big or vague

Small

Deliverable within a defined, time-boxed Iteration of 24weeksDiscrete function or requirementWrite only the Delta (the change) if part of a larger function

TestableStories must include Acceptance CriteriaStories must be testable and demonstrable

7


8/12

Acceptance CriteriaTest Cases

Acceptance Criteria are clearlydefined conditions, that can be

tested and demonstrated, required

to be met in order for Product

Owner acceptance.

Acceptance Criteria can take the formof a statement such as:

Able select a Sales Order based on

Customer Name

Able to validate Calculated Cost

prior to posting

Able to Cancel an Order that has

not been processed

Able to view Cancellation

Confirmation screen

8

Test Cases should be created foreach Story, based on defined

Acceptance Criteria, that defines the

steps necessary to validate the

functionality (enables the team to, at

a minimum, Unit test and User test.

Test Cases (may also be referred to as

Use Cases) define the key process

steps that need to be satisfied, such

as: CSR selects Sales Order based on

Customer Name CSR clicks [Cancel Order] button

CSR selects an appropriate

Rejection Reason Code

CSR clicks [OK] when prompted to

confirm cancellation and view

confirmation screen


9/12

Structure a good User Story

Defined Role

Requirement

Justification

It starts with a very big Story, then we refine and decompose it until it is clear, concise

and deliverable as stated9


10/12

Splitting Stories by Role

Improving and Refining Stories

Removing Ambiguous

Terms

Splitting Stories by

Scenario

-By Author Name

-By Genre

-By most popular

-Matching Results

-No matching Results

-Too many matching Results

-As a New User

-As a Registered User

-As a Power User

10


11/12

If its too big, we break it down

As a customer,I want to buy books

online

so that I dont have

to leave my home

As a customer,

I want to search for

a book

so that I can find the

book I want to buy

As a customer,I want toadd books to

a shopping cart

so that I can compile

the list of books to buy

As a customer,

I want to buy my books

with a credit card

so that I can pay for

the books I want

As a customer,I want to search for

a book by title

so that

As a customer,I want to search for

a book by author

so that

As a customer,

I want to search fora book by subject

so that

11


12/12

Wrap-Up

Q & A

Hands-OnNow lets do it

12

agile training - user stories and backlog

Documents