Agile Training

Agile Product Backlog and Stories

For Internal Use Only

Agile Process Overview

Vision
Jan May Aug Dec

Product Roadmap Update Backlog as needed

Product Backlog
Daily Stand-up Meeting

Prioritization

24 hours

Adapt

Inspect 2 to 4 Weeks
Features Epics Stories Stories Iteration Planning Tasks defined / expanded by team

Retrospective

Deliverable*

Release Backlog
2

Iteration Backlog

Iteration

* Demonstrable, working system

Product Backlog
The Product Backlog is the master list of all functionality desired in the product, that evolves iteratively throughout the entire project.
Product Backlog items, referred to as Stories, are typically user-centric, hence the term User Stories, but will also include technical and other non-functional stories 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 will collaborate 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

The Lifecycle of a Story

Story (Narrative) As a user, I want to be able to add books to my shopping cart so that I can buy them 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 Story Discovery On-going, looking ahead 1-2 iterations, planned Release
4

Tasks
Build UI

Setup DB
Update Front-End Build Web Service Update Tech Design DB Testing Front-End Testing

Backlog Grooming On-going, prior to Iteration planning (just in time)

Iteration Planning Beginning of each Iteration

Requirements / Backlog Decomposition

*SAP example

Release
Theme 1 Theme 2 Theme n

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

Theme
Epic 1 Epic 2 Epic n

Process Level 2
i.e. Sales Order Process

Epic 1
(aka. Feature)
Story 1 Story 2 Story n

Blueprint Document level

i.e. BPxxx_Standard_Order_Process

Story 1
Task 1 Task 2

Detailed Requirement / Process Step level

i.e. Create Standard Order

Task 1
Unit of Work
i.e. BPxxx_B_001 *May be a Business Requirement, RICEFW, Configuration, etc

Task n
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)

What is a Story?
The User Story represents customer requirements rather than documents them 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 the User/Customer Also includes requirements of System or the team - these are referred to as nonfunctional stories Includes "Acceptance Criteria, which are clearly defined conditions, that can be tested and demonstrated, 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 <user/role>, I need to <action/function>, So that <goal/justification/benefit>

As a customer service rep , As I need a System to cancel , an order, at the I customers need to Map request, Master Data changes so that I can , so provide that I can quality enable Sales customer Order service Processing . steps.

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 criteria make them terribly effective on design projects.

INVEST in quality Stories

I N
Independent
Independent Write closed, self-contained Stories Able be completed as a distinct deliverable Vertically slice through the architecture and/or functionality Negotiable Not contracts or detailed requirements Too much detail gives impression of false precision or completeness Flexibility drives release schedule and goals Valuable (to Users/Customers) Write stories in the voice of the customer Write from perspective of a single User, if applicable Estimable Stories are for planning and tracking Requires domain knowledge and expertise on the team Cant be too big or vague Small Deliverable within a defined, time-boxed Iteration of 2 4 weeks Discrete function or requirement Write only the Delta (the change) if part of a larger function Testable Stories must include Acceptance Criteria Stories must be testable and demonstrable

Negotiable
Valuable Estimable Small Testable

V E
S T
7

Acceptance Criteria Test Cases

Acceptance Criteria are clearly defined conditions, that can be tested and demonstrated, required to be met in order for Product Owner acceptance. Acceptance Criteria can take the form of 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

Test Cases should be created for each 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

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 stated
9

Improving and Refining Stories

Splitting Stories by Scenario Removing Ambiguous Terms Splitting Stories by Role

-Matching Results -No matching Results -Too many matching Results -By Author Name -By Genre -By most popular -As a New User -As a Registered User -As a Power User

10

If its too big, we break it down

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 to search for a book by title so that

As a customer, I want to buy books online so that I dont have to leave my home

As a customer, I want to add books to a shopping cart so that I can compile the list of books to buy

As a customer, I want to search for a book by author so that

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 subject so that

11

Wrap-Up

Q&A

Hands-On Now lets do it

12