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

Presented by: In partnership with:

Creating and Maintaining the Product Backlog

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

‣ 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

Agile Planning

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

precision‣ Just-In-Time approach

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

Themes

‣ Group similar stories into product themes

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

Product Vision

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

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

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)

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.

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

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?

User Stories

‣ Brief, simple requirement statement from a User perspective

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

• Card, Conversation, Confirmation

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

‣ 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

calling my doctor.

User Story

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

User Stories

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

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.

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

‣ Valuable• Should show value to:

- Users- Customers- Stakeholders

‣ Agile teams understand the subjective nature in defining quality

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

• Too big• Insufficient information• Lack of domain knowledge

‣ 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)

riorit

PRODUCT BACKLOG

✴ Release schedule timeframesare examples only

‣ 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

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

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.

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

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

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

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

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

Retrospective

Sprint Review

Story Review

Retrospective

Sprint Review

Release Plan

DemoSprin

Sprint Planning

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

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

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

Documents

scrum strategy sprint cycles roles powerpoint presentation...

scrum - sensei.ee · the sprint review, and the sprint...

inf5120 ”modellbasert systemutvikling” ”modelbased...

scrum reference card - scaled agile | scrum...scrum...

agile scrum sprint length: what’s right for you?

scrum in der anwendung - sprint planung

agile scrum sprint length: what's right for you - cognizant

scrum process sprint cycles roles powerpoint ppt templates

displanner (distributed scrum/sprint planner)

scrum sprint planning

scrum strategy sprint cycles roles powerpoint ppt templates

scrum strategy sprint cycles roles powerpoint presentation...

help!!! the scrum master is the impediment! · sprint...

methodologies: extreme programming and scrum...components of...

mejorando scrum, un sprint a la vez

agile scrum sprint length: what's right for you - … ·...

scrum methodology. sprints. sprint planning. · scrum...

scrum process sprint cycles roles powerpoint presentation...

the game of team culture (hacking) · 2014-08-27 · scrum...

agile processes: scrum. project management emphasis based on...