outcome-driven product backlog management by mike dwyer - agile maine day 2016

Copyright © 2016 SolutionsIQ Inc. All rights reserved.

6801 185th Ave NE, Suite 200Redmond, WA 98052solutionsiq.com1.800.235.4091

Outcome-Driven Product Backlog ManagementAn Empirical Approach to Refining and Ordering a Product

Backlog

PREPARED BY

Mike DwyerCST, MBASenior Agile [email protected]


Twitter: MikeD999Linkedin: www.linkedin.com/in/michaelfdwyer/

•Agile Coach •Certified Scrum Trainer •Coaching Focus – Starting/Scaling Product Development, QA, Test, and Architecture

•20+ years experience in New Product Development, Lifecycle Management, Operations in Healthcare, Finance, Technology, Manufacturing, Public Sector.

•15 years manufacturing / supply chain management

Mike Dwyer | [email protected]


Who We Are

» At SolutionsIQ, helping companies navigate the complexities of

an Agile transformation is what we do best.

» SolutionsIQ provides a comprehensive scalable (up and down)

transformation solution that delivers measurable and lasting

results.

» 35 years of professional experience and twelve years in the

Agile industry, we have successfully integrated Agile and Lean

principles into our internal operations.

» A focus on the Fortune 1000. We help our clients achieve

Business Agility through organizational change, team and

engineering services, and management consulting.

» To meet the needs of our widely dispersed clientele, we have

over 200 consultants in the US, 3 US geographic centers, and

our own office in India with over 30 consultants.


Backlog Refinement

I think your Backlog needs some refinement here.

ProductOwner

Sprint Planning Meeting

ProductBacklog


Backlog Refinement

ProductOwner

Sprint Planning Meeting

ProductBacklog


Outcome-driven Product Backlog Management

Based on : Mike Cohn, Mountain Goat Software

Sprint

Release

FutureRelease

Low

High

Ord

er

BacklogRefinement

Release capable



GOAL


Based on : Mike Cohn, Mountain Goat Software

Sprint

Release

FutureRelease

Low

High

Ord

er

Cla

rity

Complex

SimpleBacklogRefinement

Release capable



Customer needs & expectations fill the Backlog•The Three C’s

• Card• Conversation• Confirmation

•Best Practices:• No Technobabble• Can be understood

by the entire team• Contain a justification

As a customer, I want to search for a

book by title so that I can find the

book I want to buy

I will know this is done when I can…1. Get valid results based on a partial title search2. Get valid results based on a complete title search3. See suggestions for titles if my text returns no matches

Good User Stories don’t appear just because you filled in all the blanks correctly.


As a customer, I want to buy books online

As a customer,I want to search for a book…

As a customer,I want to add books toa shopping cart

As a customer,I want to buy bookswith a credit card

As a customer,I want to search for a book by title

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

As a customer,I want to search for a book by subject

Splitting Stories focuses on deliverable Outcome


And Test Cases make the difference,

Goal(Capability)

RBS/Epic

RBS/Epic

User Story

Test CaseTest CaseTest Case

User StoryTest CaseTest CaseTest Case

User Story



User Story



Goal(Capability)

RBS/Epic


in a test first way

RBS/Epic


Creating an Actionable Goal - Begin at the end.

Test CaseObjectively validate Customer’s Expectations have been met

DoR

DoD

Defines/describes the minimal amount of information needed to create a test case.


DoD DoR

User StoryNegotiableFocus on WHAT - No TechnobabbleDecomposition of Epic

• Same Actor• Action is 1 Epic Acceptance criterion• Same Outcome

Acceptance Criteria refines/clarifies what validates customer’s expectation


DoR

DoD


Defines/describes the minimal amount of information needed to support a deliverable User Story


DoD DoR

Really Big Story / EpicNegotiableFocus on What - No TechnobabbleSpecifies• Specific Actor• Specific Action (often ambiguous)• Specific Outcome (often complicated)• Acceptance Criteria reflecting

• Business Logic





DoR

DoD

DoR

DoD


Defines/describes the minimal amount of information needed to Support a release capable RBS / Epic.


DoD DoR

Actionable Goal Not NegotiableFocus on What - NoTechnobabbleIdentifies• Long Term View (< 2 years)• Categories of Actors, • High Level Features, • Deliverables.


• Business Logic





DoR

DoD

DoR

DoD



Goal-driven Story Decomposition

DoD DoR

Actionable Goal Not NegotiableFocus on What - NoTechnobabbleIdentifies• Long Term View (< 2 years)• Categories of Actors, • High Level Features, • Deliverables.


• Business Logic




TasksTechnobabble needed Work elements team doesto deliver validated expectations

DoD


DoR

DoD

DoR

DoD


Handling Challenged StoriesEarly detection that a key feature or function cannot be delivered as expected gives us more time to find options and manage expectations.This approach offers the following pattern when a story cannot be promoted.

Promote

Challenged

Future

Spike

Promote

Escalate


Product Owners are facing more challenges


BacklogRefinement

Source: Mike Cohn, Mountain Goat Software

Sprint

Release

FutureRelease

Low

High

Ord

er

The challenges in Backlog Management are daunting


ProductOwner

Project Management

The Team

Sales

ManagementMarketing

Documentation

OperationsThe Scrum Team

Government - Legislative

Analysts

Customer Support

Partners

Industry Groups

Training

Customer Team

Quality Assurance

ScrumMaster

Stakeholder Team

Market Place

End UsersCompetitors

Media

Shareholders

A difficult balance between inward and outward focus

Inside the Product Owner’s World


ProductOwner

The Team

Marketing

OperationsThe Scrum Team Analysts

Customer Support

Training

Customer Team

ScrumMaster

Product Collaboration is an emerging solution

Outside the Product Owner’s World

Project Management

Sales

Management

Documentation

Government - Legislative

Partners

Industry Groups

Quality Assurance

Stakeholder Team

Market Place

End UsersCompetitors

Media

Shareholders

ProductManager


Backlog Refinement – The Really Big Story

I think your Backlog needs some refinement here.

Size the

testability


ScrumMaster

The Product Owner has a team to count on

TeamProduct Owner


Product Increment

SprintRetrospective

Scrum Planning Meeting

Sprint Backlog

Sprint1-4 weeks

Scrum

• All the Skills Needed to deliver acceptable value• Incrementally turn Product Backlog into potentially Shippable Product• Become self organized• Collaborate on defining Definition of Done• Size Stories• Estimate Tasks• Report Progress during a Sprint• Report Impediments as they arise

SprintReview

Development Team’s Responsibilities in the Backlog

DefinitionOfDone


The Scrum Master serves the Product Owner in several ways, including:

• Finding techniques for effective Product Backlog management;

• Helping the Scrum Team understand the need for clear and concise Product Backlog items;

• Understanding product planning in an empirical environment;

• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize deliverable value;

• Understanding and practicing agility; and, • Facilitating Scrum events as requested or

needed. Product Owner

Scrum Master

Scrum Master serves the Product Owner


Product Increment

Backlog Refinement

Product Vision,Mission, Purpose

Scrum Planning Meeting

ProductBacklog

Member of the Scrum TeamProvides ‘one business’ voice to the team

• Defines overall product goals and visions• Collaborates on defining Definition of Done• Collaborates with a team of business advisors.• Participates in Test Planning• Accepts work done by the team

Leads Product Backlog Refinement• Orders User Stories• Maintains enough detail in the Backlog to support the

next level of planning• Sprint planning• Release planning

Accept Work

The Product Owner may do this work, or have the Dev Team do it. However, the Product Owner remains accountable.

Product Owner’s Primary Responsibilities

DefinitionOfDone


Goal Driven User Story Refinement Decomposition

Based on: Mike Cohn, Mountain Goat Software

Sprint

Release

FutureRelease

Low

High

Ord

er

Cla

rity

Complex

Simple


5 min to discuss with team

10 min class discussion

Wrap Up Discussion – Your Backlog challenges


Thank you


Addendum


Tasks - “HOW” to build the validated User Story

Activities needed to create the expected outcome of the story.

• Focus on passing the functional test cases they are linked to.

• Test cases guide the development and deliver the expected outcome described in the User Story.

• Adhere to technical and organizational standards.

• Task statement description is best left to the team doing the work.


Test Cases - “WHAT” validates a User Story

• Reflect the expected functionality and be written in business context.

• Describe what validates an User Story • Small enough to complete in a sprint.

• Test Cases focus on validating that the expected business functionality works as agreed.

• Test Cases must iteratively expand to support Continuous Delivery and DEV OPS efforts as these become accessible to teams.


User Story – Describes the validate-able Outcome

• The Development Team and the Product Owner agree on how to validate the story is done and commit to having it accepted in a sprint.

• The Acceptance Criteria refine and clarify what needs to be done to the point where the work can be validated.

• Many Regulatory, governance, documentation requirements should be considered acceptance criterion


Epics / Really Big Stories cannot be done in a Sprint

RBS / Epics are User Stories that the Product Owner, Product Manager, Scrum Team are confident:• RBS Acceptance Criteria reflect

Business Logic. These acceptance criteria can consist of 5 types of acceptance criterion – “Yes, No, Maybe, We don’t know, and You’ll figure it out.”

• The RBS / Epic cannot be done is a sprint.

• The testability of the RBS / EPIC can be estimated/sized.


Actionable Goals are the Key to Successful Backlogs

• A View reflecting the direction as well as the scope of the desired capability.

• Duration determined by the context of the observable and measurable outcome

• The group(s) of Actors reflect types of users (business titles) this goal supports.

• The High-Level Features you believe the Actors will use.

• The Deliverables describe what we expect the Actors to find useful and valuable. This includes governance, regulatory, compliance deliverables that is represented by an Actor.

outcome-driven product backlog management by mike dwyer - agile maine day 2016

Education