Vous êtes sur la page 1sur 12

Agile Training

Agile Product Backlog and Stories

For Internal Use Only

Agile Process Overview

Jan May Aug Dec

Product Roadmap Update Backlog as needed

Product Backlog
Daily Stand-up Meeting


24 hours


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



Release Backlog

Iteration Backlog


* 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.

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

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

Theme 1 Theme 2 Theme n

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

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

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

Valuable Estimable Small Testable


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


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

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


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




Hands-On Now lets do it