Agile Product Management with Scrum summarized
Agile Product Management with Scrum summarized
In which I summarize Roman Pichler’s book on product management in Scrum, on transitioning into the product owner role.
——
The product owner is responsible for the business value of the work of the Scrum team and for the resulting product, and has corresponding authority over the product backlog and the product. The product owner says what needs doing, not how to do it or how much it will take.
The product owner needs organizational support and trust with sponsorship from upper management. Organizational recognition of the authority and responsibility of the product owner role is a critical success factor for Scrum adoption.
This is a full time job. Relieve the product owner of all other responsibilities.
In exercising these responsibilities the product owner is a team player who involves stakeholders and is radically accepting of feedback and seeking of customer input in evolving the emergent product backlog. Invite stakeholders to the sprint review, which is about being honest not about impressing. Shield the team from change during the sprint and from noise about what might come up, channeling the needs that really have come up so that the team can productively engage with and resolve them.
The product owner should rally the team around a product vision and should articulate a product roadmap on a realistic planning horizon (maybe 6-12 months).
Product backlog grooming is a collaborative, shared, team activity best undertaken with paper.
The product backlog absolutely must be well-groomed going into sprint planning. Undertaking a sprint under conditions of neglected grooming can yield negative value. The product owner does not plan the sprint - only the team can commit itself to a sprint backlog.
Release planning should be done as a team, with the product owner driving.
Ship less sooner, attacking the areas of greatest risk and uncertainty. This gains sooner feedback, maximizes the area under the value curve, and avoids going down the wrong roads as far. Absolutely release something at least every quarter. Cut scope, cut scope, and then cut scope some more.
Have a definition of done and use conditions of satisfaction to express non-functional requirements. Never accept unfinished or defective sprint backlog items. Be courageous about this without being a jerk. He (very) hard on the product without being hard on the humans.
Never compromise on quality, and pull as much testing and quality control into the sprints as possible.
The Scrum team is self-organizing. Do not interfere. Try asking questions. Be available to be part of the solutions identified through the inspect and adapt retrospective process.
Get a coach.
Mistakes to avoid:
- Entrusting insufficient authority in the product owner
- Product owner as committee
- Splitting product owner role amongst multiple people
- Over-working the product owner
- Failing to relieve the product owner of (all) other responsibilities,
- Insufficient team support for the product owner,
- Distance
- Proxy product owner
- No vision
- Prophecy vision
- Analysis paralysis
- We know what is good for our customers
- Big is beautiful
- Requirements over-specification
- Wish list for Santa
- Requirements push
- Grooming neglect
- No release burndown or plan
- Product owner not driving the release plans
- Big-bang release
- Quality compromises
- Bungee product owner
- Passive product owner
- Unsustainable pace
- Smoke and mirrors
- Reporting up the sprint burndown
This post is part of a series
I have summary posts for each chapter of the book:
- Preface
- Chapter 1 : the product owner role
- Chapter 2 : product vision
- Chapter 3 : product backlog
- Chapter 4 : release planning
- Chapter 5 : Scrum meetings
- Chapter 6 : Transitioning into the product owner role
Read the book
It’s a good book; you should read it.
While I hope my summary is helpful, the book has more nuance, detail, and examples.