Product Owner Anti-Patterns - StickyMinds · Certified ScrumMaster Training Anti‐Pattern: Copy...

AT4 Class 6/9/2011 12:45:00 PM

"Product Owner Anti-Patterns"

Presented by:

Monica Yap SolutionsIQ

Brought to you by:

330 Corporate Way, Suite 300, Orange Park, FL 32073 888‐268‐8770 ∙ 904‐278‐0524 ∙ [email protected] ∙ www.sqe.com

Monica Yap Over the past nineteen years, Monica Yap has designed and developed a wide variety of products from property tax management applications to warehouse distribution systems. Since 2000, Monica has been leveraging agile methods to deliver successful projects with teams both co-located and distributed. She became an agile coach in 2004 to help other teams and organizations adopting agile process to deliver faster results with better quality. Through training and hands-on coaching, Monica helps teams and organizations utilize the Scrum framework to deliver the highest priority features in short iterations. She emphasizes improving code quality by helping teams adopt engineering practices such as continuous integration, test-driven development, and pair programming.

Certified ScrumMaster Training

Product Owner Anti Patterns

Scrum Gathering Shanghai

April 19‐20, 2011By Monica Yap

Monica Yap

• Started software development in 1992

• Started doing Agile in 2000

• Became a Scrum and XP coach

• Still loves to pair with developers

• Loves to travel around the world

2Copyright © 2011 SolutionsIQ. All rights reserved.


Outline

• Product Owner role in Scrum

• Common anti‐patterns and why they made your project fail

• The Absent Product Owner

• The Churning Backlog

• Missing Stakeholders

• No Single Product Owner

• Copy The Old One

• The Waffling Definition of “Done”

• Q&A3Copyright © 2011 SolutionsIQ. All rights reserved.

Product Owner Role in Scrum


• The “Single Wringable Neck”

• Has the responsibility to deliver a successful product in terms of:– Vision

– Priorities

– Minimum MarketableFeature Sets

– Release Dates

– ROI – Cost




• Prioritizes features for the product

• Maintains enough detail in anticipation of the next level of planning

• Defines the product development roadmap



• Is open to the negotiations that will occur

• Is business‐oriented

• Can be Product Manager, Marketing Manager, Project Manager, or “real customer”




• Seek out stakeholders

• Get them to help define the roadmap

• Get them to help prioritize the backlog

• Seek feedback and acceptance

Common Anti‐Patterns & Why They Made Your Project Fail

• Sailing without direction from captain

• Over sail, or did not get there on time

• Sail to the wrong place

• Cannot get to destination

• Team delivers features that are: – Low priority

– Extra

– Incorrect

– Combination of all of the above8Copyright © 2011 SolutionsIQ. All rights reserved.


Common Anti‐Patterns & Why They Made Your Project Fail


Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

Always7%

Often13%

Sometimes16% Rarely

19%

Never45%

Rarely or neverused: 64%

Often or alwaysused: 20%

© 2004 Poppendieck LLC

Anti‐Pattern: The Absent Product Owner

• PO not available to provide rapid feedback to team

• Team will “self‐inspect” and make decisions

• Team delivers features that are: – Low priority

– Extra

– Incorrect

– Combination of all of the above



The Absent Product Owner: Smells• Communicates backlog and stories electronically

• Team/ScrumMaster has to maintain the product backlog

• Absent for Sprint planning/reviews

• Stories and acceptance criteria not clear

– Team has to determine acceptance criteria on their own

• Inadequate time allocated to answer questions through the Sprint

• No time to accept stories


The Absent Product Owner: Remedies

• Create a dedicated PO role and support group

• Work with organization to empower PO to devote enough time

• Designate a (full‐time) Product Owner proxy

• If none is satisfied– Raise as impediment at organizational level

– Suggest aborting the project



Anti‐Pattern: The Churning Backlog

• Sprint backlog churning after sprint planning• Team cannot stay focused

• No stability, no cadence

• A lot of waste produced (unfinished code, WIP)

• Team cannot be productive


The Churning Backlog: Smells

• New stories often added to sprint backlog during the sprint

• PO and stakeholders rationalize small changes– “This is just a clarification, it shouldn’t impact the sprint.”

– “This is the same size as X, so pull X out and do this instead.”


Team continually has to split stories to get something done during the sprint


The Churning Backlog: Root Causes

• Lack of higher level planning, i.e. Product roadmap, release plan

• PO is not fully aligned with product vision/roadmap

• No adequate backlog grooming

• Left field stakeholders


The Churning Backlog: Remedies• Pre‐plan with the PO before each sprint starts, identify concrete acceptance criteria

• Help PO and stakeholders to commit to a product vision, roadmap

• Create a release plan together



The Churning Backlog: Remedies


•Release•Product

•Iteration•Daily

•Portfolio•Strategy

•Agile teams plan at the inner most three levels•Others (in the company) plan at the outer levels.

•Source: “Agile Estimating and Planning,” by Mike Cohn

Missing Stakeholders – Anti Pattern

• All stakeholders are not identified from beginning, e.g. IT, Marketing, Customer Service

• Not enough stakeholders are involved for stories and prioritization

• Likely happen at end – “Code is ready, but it’s not ready for use”

• Worst case – Wrong decisions made without feedback from missing stakeholders



Missing Stakeholders: Smells

• When ready to release, key people speak out against the project for not delivering required functionality

• Key requirements did not surface in release planning

• Surprises came in the middle Sprints


Missing Stakeholders: Remedies• Use system tracer bullet to identify the functional or support group involved

• Find the key stakeholders from this list

• PO get stakeholders together frequently – Conduct story writing workshop

– Review priorities

– Establish rhythms



Anti‐Pattern: No Single Product

• When the organization does not allow or support single decision makers as the POs

• Sometimes SMEs start acting as Product Owners

• Team thrashes on different decisions made by multiple Product Owners

• Team wastes a lot of effort to decipher whose decision is correct

• Eventually some team member will “act” as the PO and make final decisions


No Single Product Owner: Smells

• No single person can be identified as PO

• The project sponsor is a committee

• Conflicting decisions made by different stakeholders or domain experts

• Lots of new stories created for feature rework



No Single Product Owner: Remedies

• Propose one single PO from the group of SMEs/stakeholders

• For large project– Divide into multiple teams, each with its own backlog

– Each PO can own a backlog

– Identify a chief Product Owner

– Coordinate via Meta Scrums, and Scrum of Scrums

• If none is satisfied– Raise as impediment at organizational level

– Suggest aborting the project


No Single Product Owner – Remedies


Many Teams, many backlogs

Many Teams, one backlog


No Single Product Owner – Remedies


Chief Product Owner

Product Owners

No Single Product Owner: Remedies


• Synchronize within teams

• Synchronize across teams

9:00AM9:15AM

9:30AM9:45AM

10:00AM10:15AM

•• 10:30AM

11:00AM

Daily Scrumsper TeamScrum Team 1

Scrum Team 2

Scrum Team 3

Scrum of Scrums


Anti‐Pattern: Copy the Old

• When the project is to build a new application to replace an old one

• PO does not create stories or prioritize the backlog– They are “all there in the old application”

– Just copy the old one and repeat

• Team “acts” as the PO– Learn the old application via code/spec

– What they learn is outdated

– Old system didn’t have the correct features


Copy the Old One: Smells

• PO asks the team to “just read the old spec”

• PO takes a screen shot of the old application and asks the team to reproduce

• PO refuses to prioritize or explain the stories

• PO may not know how or why the system behaves like it does



Copy the Old One: Remedies

• What do the users says about the current system?– What are the “wrong” features?

– What are the “missing” features?

– What are the features “never/rarely” used?

• Get ROI in multiple releases throughout the project, mitigating many risks– Prioritize the stories into releases

– Avoid risk of building wrong or wasteful features

• Use the “As a, I want, so that …” story template29Copyright © 2011 SolutionsIQ. All rights reserved.

A User Story Template (Card)

• Describes the value of functionality from a user’s perspective

• User – a user of product the team is developing

• Goal – feature user needs to increase value of product

• Value – why feature is important30Copyright © 2011 SolutionsIQ. All rights reserved.

User StoryAs a <<user>>

I want to <<goal>>so that <<value>>

User StoryAs a <<user>>

I want to <<goal>>so that <<value>>


Anti‐Pattern: The Waffling Definition of “Done”

• Expectation of the stories in sprint not well‐defined– No concrete acceptance criteria

• At sprint end:– “I thought you knew this was part of the story”– “BTW I forgot to tell you this”

• Team lose the sense of completion• Estimates inflated• Cannot achieve a consistent velocity• Team can never produce releasable code


The Waffling Definition of “Done”: Smells

• You should have known about doing X

• We assumed you would include X

• IT has always provided us with X

• Unless you provide X then the Y you delivered has no value



The Waffling Definition of “Done”: Remedies

• Define acceptance criteria for each story

• Complete one story at a time

• Mid‐sprint acceptance

• Adapt ‐ Update the acceptance criteria for stories in the next sprint


Confirmation Through Acceptance Criteria• Product Owner makes first pass at Acceptance Criteria before

Sprint Planning Meeting

• During Sprint Planning, Acceptance Criteria are discussed

• Final Acceptance Criteria for each User Story is a negotiation between Delivery Team and Product Owner

• Should be short, easy to understand statements


•Acceptance Criteria•View status as “waiting for pickup”, “en route” or “delivered”

•Date of each step in route

•Estimated time of delivery


Conclusion: Scrum Can Expose a Mess


Q & A

Product Owner Anti-Patterns - StickyMinds · Certified ScrumMaster Training Anti‐Pattern: Copy...

Documents

Transcript of Product Owner Anti-Patterns - StickyMinds · Certified ScrumMaster Training Anti‐Pattern: Copy...