“Creating Products that Customers Love” strikes us as highly poignant, as much of the world heads toward a holiday season with much gift-giving.
Roman Pickler’s book, “Agile Product Management with Scrum” provides the single best book, barely over 100 pages, to understand the role of Product Owner. Some even claim it remains one of the seven must-read books about the Agile mindset. Therefore, with a foreword by Jeff Sutherland, and included within the set of Mike Cohn’s signature books, take two to three hours and give it a quick read. However, it does presume some previous familiarity with the Agile Scrum framework.
Product Owner Role
Beginning with an understanding of the role of Product Owner the old-school versus new-school comparison of product management certainly reads like MG RUSH’s explanation of traditional leadership versus servant leadership. Stressing the importance of self-organizing teams, our “Nobody is Smarter than Everybody” gets duplicated with Pickler’s:
“The wisdom of many is preferred to the brilliance of one.”
- Represent the customers and the product users
- Identify and describe customer needs and product functionality
- Lead the visioning activities that bring the vision to life
- Stress teamwork and collaborative decision-making to ensure shared ownership
Envisioning the Product
Therefore the Product Owner, through the Product Backlog, converts the product vision to attributes by securing answers to solid questions such as:
- Who is going to purchase the product?
- Who is going to use the product?
- What needs do the product address?
- How much value does the product add?
- What attributes are critical for the product’s success?
- Where will the product excel?
- Compared to competitive alternatives, what are the unique selling points?
- Where and how much revenue will be derived?
- What do we need to do to win?
Pickler leans on Cockburn’s logic of prioritization, namely:
- Sacrifice others for this
- Try to keep
- Sacrifice this for others
Various methods of visioning are discussed. After that, they are combined into a product roadmap. Most of these methods are covered in detail by MG RUSH in other posts, such as:
Working with the Product Backlog
Pickler follows with evidence-based support for managing the Product Backlog. He begins by applying DEEP that he attributes to Mike Cohn:
He further suggests that Product Backlog descriptions can be detailed, or course-graining (called epics). The Product Owner is responsible for structuring and refining the Product Backlog. Items may be grouped by functionality to create themes. For instance, the calendar function is a theme of a smartphone. Each theme generally represents “between two and five course requirements. (epics)”
Next, he discusses methods of valuing or prioritizing backlog items that help the Product Owner prepare for Sprint Planning. Therefore, the Product Owner is encouraged to decompose and refine product backlog items breaking down epics into detailed user stories. This technique is referred to as “slicing the cake” (Cohn, 2004, pg 76). He also references, but does not discuss in detail, Bill Wake’s INVEST criteria (stories need to be independent, negotiable, valuable, estimable, small, and testable).
For sizing stories Pickler offers up t-Shirt sizing (XS through XXXL) and Planning Poker, using a Fibonacci scale through 13 and then substitutes 20 for 21 as Huge (or, XXXL). Today there are apps abounding for smartphones. Therefore, simply search “planning poker app” to generate numerous options for Android and iOS. Ours includes a coffee break symbol and a questions mark and includes pure Fibonacci and t-shirt sizing options as well.
In addition, his discussion of nonfunctional requirements and scaling the product backlog demand careful reading. Similarly, slow down to review his along descriptions of common mistakes when refining the product backlog such as:
- Disguised Requirements Specification
- Wish List for Santa
- Requirements Push
- Grooming Neglect
- Competing Backlogs
Other Product Owner Considerations
Finally, his book ends with commentary focused on large projects, discussing items like velocity and burn down. Prior to his final discussion of transitioning into the role of Product Owner, he stresses additional collaboration and makes comments covered by many other posts such as:
- Sprint Planning
- Definition of Done
- Daily Scrum
- Sprint Backlog
- Burn down and Velocity
- Sprint Review
- Sprint Retrospective
Therefore, every Product Owner should review this valuable book, other Sprint Team members could learn as well. After all, “Nobody is Smarter than Everybody.”
 Likewise, according to Googles 10 Golden Rules:
7. Strive to reach consensus. Modern corporate mythology has the unique decision maker as hero. We adhere to the view that the “many are smarter than the few,” and solicit a broad base of views before reaching any decision. At Google, the role of the manager is that of an aggregator of viewpoints, not the dictator of decisions. Building a consensus sometimes takes longer, but always produces a more committed team and better decisions.” — by Eric Schmidt, CEO of Google
 Defined by Ken Schwaber as: “The vision describes why the project is being undertaken and what the desired end state is.” — Agile and Project Management with Scrum (2004, pg 68)
Don’t ruin your career or reputation with bad meetings. Register for a class or forward this to someone who should. Taught by world-class instructors, MG RUSH professional facilitation curriculum focuses on practice. Each student thoroughly practices and rehearses tools, methods, and approaches throughout the week. While some call this immersion, we call it the road to building impactful facilitation skills.
Our courses also provide an excellent way to earn up to 40 SEUs from the Scrum Alliance, 40 PDUs from PMI, and 40 CDUs from IIBA, as well as 3.2 CEUs for other professions. (See individual class descriptions for details.)
Want a free 10-minute break timer? Signup for our once-monthly newsletter HERE and receive a timer along with four other of our favorite facilitation tools, free.