creating and maintaining the product backlog - aspe … · creating and maintaining the ... sprint...

Copyright 2013 Davisbase Consulting, LLC. Limited Display License Provided to ASPE

Presented by: In partnership with:

Creating and Maintaining the Product Backlog

1


Agile Coach & TrainerDavisbase Consulting

•Background in Development with 6 years IT Management leading cross-functional development teams

•Led Agile transformations from small teams to large programs over last 5 years

•Scaled Agile Framework Program Consultant (SPC), Professional Scrum Master (PSM), Certified Scrum Master (CSM)

Track the conversation on Twitter @davisbase @ASPE_SDLC #agile

Josh Fruit

2


‣ Review what makes up the Product Backlog‣ Explore who creates the Product Backlog and

why it is important‣ Discuss User Stories and their importance‣ Examine what a User Story should ‘look like’‣ Discuss what to watch out for in the Product

Backlog

Objectives

3


Agile Planning

‣ Agile practices embrace continuous planning‣ Always accurate, but with varying levels of

precision‣ Just-In-Time approach

4


The Product Roadmap

‣ Connecting the Product Vision to our approach

‣ Effective tool to provide the team with incentive and focus

‣ Not a commitment...only a plan

5


Themes

‣ Group similar stories into product themes

‣ Themes can help with planning:• Roadmap• Release• Prioritization

SECU

RITY

PRO

D. M

GM

T

CUST

. MG

MT

PAYM

ENTS

ADVE

RTIS

ING

Product Vision

6


Theme Prioritization

‣ We will determine priority at multiple levels: Themes, Epics, User Stories

‣ Prioritization of Themes may not be linear (you may have themes represented more than once at different points on the roadmap)

‣ Can help establish your roadmap

7


Roadmap Examples

Jan Feb Mar Apr May JunSecurity

User AdminPayments

Fulfillment

Product Admin

Q1 Q2 Q3Security

User Admin

Payments

Fulfillment

Product Admin

Security

User Admin

8


Product Backlog

‣ A prioritized list of all user stories that may be delivered

‣ New items can be added at any time to the Product Backlog

‣ Items are defined, prioritized, sequenced by Product Owner with input from others

‣ Team members estimate items in Product Backlog relative to each other using predetermined scale (story points)

9

Copyright 2013 Davisbase Consulting. Licensed for Classroom Use Only.

Product Owner Role

‣ Critically important for the success of an Agile project

‣ A great product owner should be:• Available. To the team.• Knowledgeable. About the product.• Empowered. To make business decisions.

‣ A part of the team, not apart from the team.• The business and development team must act as true

partners in order to succeed.

10

Copyright 2013 Davisbase Consulting. Licensed for Classroom Use Only.

The Agile Team‣ Product Owner

• Product Vision and Roadmap

• Manage the Product Backlog

• Be prepared with details at the appropriate time

• Set clear expectations for acceptance

• COMMUNICATE

‣ Team Member• Estimate our work• Plan and commit for the

iteration• Execute the iteration• Demo the completed

features• Retrospective• COMMUNICATE

What is needed How do we deliver

11


User Roles

‣ Why are User Roles important?‣ Unique perspectives change requirements and

acceptance criteria‣ Who are your target customers?

• What do they use the software for?• How do they use the software?• What are their priorities?

12


User Stories

‣ Brief, simple requirement statement from a User perspective

‣ Acceptance criteria‣ Documented and visible‣ Ron Jeffries’ Three C’s

• Card, Conversation, Confirmation

13


As an instructor, I want to post my presentation online

so that I do not need to send it.

As a patient, I want to access test

results online, so that I can get them at my convenience without

calling my doctor.

User Stories - Examples

14


‣ Agile requirements are written from a customer’s perspective, in plain language to minimize the barrier to customer involvement.

‣ Understanding the why can be as important as the what.

‣ Information gems exist in knowing why our customers want what they ask for.





calling my doctor.

User Story

15






calling my doctor.

What

Why

What

Why

Who

Who

User Story

16


Agile Requirements

Ability for user to post a presentation online.

Traditional Requirements





calling my doctor.

Enable Patients to have access to test results

online.

Why the Why

17


User Stories

‣ INVEST acronym (Bill Wake)• Independent• Negotiable• Valuable• Estimable• Sized appropriately• Testable

18


User Stories: INVEST

‣ Independent• Avoid dependencies with

other stories whenever possible

• Able to deliver as a product increment independently

As a patient, I want to access test results online,

so that I can get them at my convenience without calling

my doctor.

As a patient, I want to login to my online account so that

I can see my account information securely.

19


As a patient, I want to access test results online,

so that I can get them at my convenience without calling

my doctor.

As a patient, I want to access all past test results

online, so that I can get them at my convenience

without calling my doctor.


‣ Negotiable• Stories are NOT a contract• Too much detail up front

gives the impression that more discussion is not necessary

• Create foundational stories if necessary

20



‣ Valuable• Should show value to:

- Users- Customers- Stakeholders

‣ Agile teams understand the subjective nature in defining quality

21



‣ Estimable‣ Enough detail to allow the team to estimate‣ Challenges estimating if...

• Too big• Insufficient information• Lack of domain knowledge

22



‣ Sized Appropriately• Small enough to be

completed in a single iteration if possible

• Small for the near future• Larger stories are okay

further out (Epics)

0 - 6

Mon

ths

*CU

RREN

TRE

LEAS

E SC

HEDU

LE

6 - 1

2 M

onth

s *

FUTU

RERE

LEAS

E SC

HEDU

LE

12 +

Mon

ths

*FU

TURE

RELE

ASE

SCHE

DULE

LOW

P

riorit

izat

ion

H

IGH

PRODUCT BACKLOG

✴ Release schedule timeframesare examples only

23



‣ Testable• Acceptance criteria stated

in customer terms• Automate whenever

possible• All team members should

demand clear acceptance criteria

As a retiree, I want to see a summary of my investment accounts on one screen so that I can decide where to

focus my attention

• All investment accounts linked to the user profile

• Account number, name, total value today displayed

24


What to Watch Out For‣ Mike Cohn’s ‘Catalog of Story Smells’

• Stories that are too small• Stories too big....too many being split later• Interdependent stories• Goldplating• Too much detail• Interface detail too soon• Thinking too far ahead• Lack of customer participation,

writing and prioritizing

25


Non-User Stories‣ Technology foundation

stories• At times these can be stated

in customer terms

‣ Dependencies from external teams

‣ Creative elements‣ Spikes‣ Other types of stories...

defects, maintenance, training, etc.

As a developer, I want to upgrade to the latest version of the database software so

that we have a supported product

Spike: As a developer, I need to investigate a semantic

search algorithm to facilitate natural language searching of the person’s financial record.

26


Non-User Stories: Constraints

As a patient, I want the system to function like the other systems in the suite

so that it is familiar and easy to use.

As a stakeholder, I want page load times to conform to current standards so that patients will be able to use

the system on a dial-up connection.

‣ Constraints often do not represent user functionality

‣ Should be documented and remain visible for team, but does not go into the product backlog

‣ Should be stated in measurable terms and be testable

27


Story Review

‣ As the team prepares stories for an iteration, more detailed collaboration is necessary for some stories

‣ Level of formalization should be determined by the team

‣ Ensure the team is engaged and collaborating

28


Story Review - Methods

‣ Whiteboard discussion‣ Use Cases‣ Process flows/diagrams‣ Requirements/Design Documentation - please

ensure this is done as a result of collaboration, NOT in place of collaboration

‣ Screen Mockups‣ More ideas...

29


Sprint Zero

‣ Some teams use a Sprint 0 to prepare their Product Backlog, infrastructure, etc.

‣ Keep it as short as possible (1-2 weeks max.)‣ Goals:

• Get some quality items on the Product Backlog• Provide a minimal environment to enable writing and

testing of code• Make proper, effective planning of Sprint 1 possible

30


Process OverviewSp

rint 1

Mon Tues Wed Thur FriSprint Planning

Daily Scrum

Story Review

Daily ScrumDaily Scrum

Daily ScrumDaily ScrumDaily Scrum

Daily ScrumDaily ScrumDaily ScrumDaily Scrum

Daily Scrum

Daily ScrumDaily Scrum Daily Scrum

Daily Scrum

Daily Scrum

Retrospective

Demo

Sprint Review

Story Review

Retrospective

Sprint Review

Release Plan

DemoSprin

t 2

Sprint Planning

31


Summary Highlights‣ Product Owner role is the “content authority”

for the Product Backlog‣ Development Team including developers and

testers gives input to the Product Backlog and determines the “how”

‣ Both Product Owner and Development Team collaborate routinely on shaping, sizing and sequencing user stories in the Product Backlog

‣ Product Backlog is dynamic and evolves over time

32


Thank you!

Now is the time for questions!

Remember, any unanswered questions will be captured and responses provided online.

www.davisbase.com

@davisbase

STAY CONNECTED

www.aspe-sdlc.com

@ASPE_SDLC

33

creating and maintaining the product backlog - aspe … · creating and maintaining the ... sprint...

Documents