Agile Product Management with Scrum [book notes]

Create Products That Customers Love with Roman Pichler [book learning]

The book is a guide for becoming an excellent Product Owner (PO) using the SCRUM framework. It focuses not only on SCRUM but also on product management, which is essential learning for a great PO. Pichler covers everything related to product management: from how to create a vision for your product, roadmaps, build and manage the product backlog, plann releases, and work with your development team.

Here are my notes from reading the book, not much of a book review, but it will give you an idea about the area you want to look into. So grab the book after you read this, it’s a very good read.

1. Understanding the PO role

the PO leads the development efforts to create a product that generates the desired benefits
- create product vision
- groom the backlog
- plan the release
- involve customers, users, other stakeholders
- manage budget
- prepare product lunch
- attend SCRUM meetings
- collaborate with the team
is part of the SCRUM team
qualities of a PO:
- visionary and doer
- leader and team player: don’t dictate but also don’t be laissez faire; let the team input and get their buy-in
- communicator and negotiator
- empowered and committed
- available and qualified (understand customers, market, passionate about UX, ability to communicate needs, manage budget, guide a dev project, cross-functional teams, self-organising teams)
PO and SCRUM Master:
- PO is responsible for “what” – creating the right product; SM is responsible for “how” – use SCRUM in the right way
- an individual should not be PO and SM
PO takes on the responsibilities of Product Marketer + Technical Product Managers
big SCRUM projects:
- Chief Product Owner on top of POs
common mistakes:
- the underpowered PO
- the overworked PO
- the partial PO
- the distant PO
- the proxy PO
- the PO committee
questions to apply the PO role successfully:
- who represents customers and users and your company?
- who identifies and describes customer needs and product functionalities?
- who leads the visioning activities, and who leads the activities that bring the vision to life?
- what role do team work and collaborative decision making play?
- what would it take to implement the PO role, as described in this chapter?

2. Envisioning the product

The Product Vision
- = sketch of the future product
- answer the questions:
  - Who is going to buy the product? Who is the target customer? Who is going to use the product? Who are its target users?
  - Which needs will the product address? What value does the product add?
  - Which product attributes are critical for meeting the needs selected and therefore for the success of the product? What will the product roughly look like and do? In which area is the product going to excel?
  - How does the product compare against existing products, from both competitors and the same company? What are the product’s unique selling points? What is its target price?
  - How will the company make money from selling the product? What are the sources of revenue and what is the business model?
  - Is the product feasible? Can the company develop and sell the product?
- how a vision should be:
  - shared and unifying: involve the SCRUM team into creating the vision
  - broad and engaging
  - short and sweet
    - the vision is not a feature list
    - select 3-4 features of the products that would make people buy
    - don’t make lists
    - clear and simple value proposition
- minimal marketable product:
  - product with minimum functionality that meets the selected customer needs
- techniques to create the vision:
  - Prototypes and Mockups:
    1. plan: develop a hypothesis
    2. do: validate it
    3. check: review the results
    4. act: redo the process is the idea wasn’t validated or implement findings
  - Personas and Scenarios
    - persona = avatar; customer profile; has a name; job, skills, interests
    - customer empathy map
    - customer journey map
    - sequences and storyboards
    - user cases and user stories
  - Vision Box and Trade Journal Review
    - vision box = mockup of the package in which the product might ship
    - trade journal = what would you like to read about the product once it’s launched?
  - the Kano Model
    - helps select the right functionality to create an attractive product
    - it tells us how satisfied the customer is likely to be
    - 3 types of functions: e.g. mobile phone
      - basics: switching on and off, calls, messages
      - performance: “the more, the better” => the more quickly the phone turns on, the more satisfied the customer; so any performance upgrade is welcome
      - delighters: delight and excite the customers; differentiate the product on the market; design, personalisation
- visions are likely to focus on delighters and performance, not the basics; in time performance become basics and delighters become performance, as the product needs to be continuously developed
The Product roadmap:
- product versions
- simple, focused on essentials
- for each version:
  - launch date
  - target customers and needs
  - top 3-5 features
- details will be captures in product backlog
- include the scrum team when developing it
- make it realistic -time-wise
- focus on the next 6-12 months only
Common mistakes:
- no vision
- prophecy vision
- analysis paralysis
- “we know best what is right for our customers”
- big is beautiful but not efficient: iterate rather than going big from he beginning; release early and frequently; refer to a set of customers to begin with; incorporate customer and user feedback; launch quickly, inspect the market response, adapt the product accordingly

3. Working With the Product Backlog

Qualities of the Product Backlog:
- Detailed appropriately:
  - higher priority issues described in more detail
- Estimated:
  - story points or ideal days
- Emergent:
  - content changes frequently
  - existing items are modified, prioritised, reprioritised, refined, removed
- Prioritized:
  - top of the backlog = high priority items
Grooming
- ongoing process
- steps:
  - new items discovered & described, existing ones changed & prioritised
  - prioritised
  - high-priority items: decomposed and refined
  - size the items
- grooming is a collaborative process: PO and team (10% of team time should be on grooming)
- team members co-author requirements
- face-to-face discussion with team, PO, Scrum Ma
- establish a process: after daily scrum, weekly, at sprint review
- use paper cards?
- 4 steps of grooming process:
1. 1. Discovering and describing items
    - Discovering Items
      - collaborative effort: team + stakeholders
      - focus on minimum functionality needed for the product, not the items
      - focus on the critical and don’t worry about the future now
      - don’t add too much detail now; items are detailed progressively, based on their priority
      - non-functional criteria don’t need details
      - low priority items get details when they become a priority
      - discover new items in:
        
        grooming workshops
        
        sprint review meetings
        
        customer and user comments
      - items should have a well understood customer need behind
    - Describing Items
      - stories:
        
        name
        
        brief narrative and
        
        acceptance criteria
      - coarse-grained stories = epics
      - keep it simple
    - Structuring the backlog
      - stories are grouped into themes
      - distinction between epics and detailed stories
  2. Prioritise the backlog – factors based on which we prioritise
- - - Value:
      - an item is valuable if it is necessary for bringing the product to life; if not the case – no value => reprioritised, discard it etc.
      - before including an item in the release, decide if the product could still achieve the desired benefits without that item
    - Knowledge, uncertainty, risk:
      - uncertain and risky items = high priority
      - tackle uncertainty and risk early, fail early if the case
    - Releasability:
      - release early and frequently, to let software evolve into a product that customers love
    - Dependencies:
      - resolve them as soon as possible
Getting ready for Sprint Planning
- Choosing sprint goal
  - summarises the desired outcome of the sprint
  - broad, but realistic;
- Preparing just enough items just in time
- Decomposing items
  - make items smaller and smaller, to fit in the sprint
  - = progressive requirements decomposition
  - if acceptance criteria are more than 10, or requirements hide in the criteria, we need to decompose the story
- Ensuring clarity, testability, feasibility
  - clear = all Scrum team have a common understanding of the semantics
  - testable = there’s an effective way to determine whether the requirement is satisfied within the sprint in which it is implemented => acceptance criteria
  - feasible = it can be completed in 1 sprint, acc. to team definition of “done”
Sizing items:
- Story points
  - = relative measure of effort and size
  - they make sense in relationship to each other only
- Planning poker
  - every team member is given a deck of cards that contains all of the agreed-upon story point values – estimation starts
Non-functional requirements: performance or UX requirements (operational requirements)
- Describing them
  - can be expressed as constraints
  - e.g. system must reply in 1 second
- Managing them
  - distinguish: global vs local
  - example of global:
  - useful to incorporate them in the definition of done
Scaling the product backlog
- Use one Product Backlog
- Extend the grooming horizon
- Provide separate backlog views
Common mistakes:
- Disguised requirements specs …into a backlog
- Wish list for Santa
- Requirements push ->the PO writes the backlog alone and pushes it to the team
- Grooming neglected
- Competing backlog

4. Planning the release

5. Collaborating in the sprint meetings

Sprint planning
- make sure the backlog is well groomed (detailed + prioritised)
- clarify requirements, answer questions
- role: help team understand what must be done
- team: figure out how much can be done and how to do it
- you don’t tell the team how much to do, they will estimate, and create a sustainable pace of moving on projects
- a commitment is not a guarantee
Definition of Done
- done = usually = product backlog items are transformed into working software that is thoroughly tested and adequately documented: implement + test + document in the same sprint
Daily Scrum
- do not identify or assign tasks and don’t make any comments on the progress achieved by individuals: ask questions instead
Sprint Backlog and Sprint Burndown
- neither is intended as report for the stakeholders
- if the stakeholders are interested in the progress, they can observe quietly the Daily Scrum and sprint review meeting
Sprint Review
- stakeholders can participate at the review
- low-key meeting, not a show, no formal presentation, no slides
- scope of the meeting: transparency and inspect / adapt the product
- PO:
  - kick-off meeting by comparing the product increment to the sprint goal => progress?
  - review each product increment and accept / reject each product backlog item committed by the team
  - you can run a few test if needed
  - make sure the ones accepted comply with the definition of done
  - never accept unfinished or defective items
  - feedback to the team: honour their effort, praise, express disappointment if the case, address always entire team, not one individual
  - ask stakeholders for feedback on the product increment
  - you can always carry on just-in-time reviews in case you need it, you don’t have to wait for the sprint review
Sprint Retrospective
- improvement measures + strengthen the relationship with the Scrum team
Sprint Meetings on Large Projects
Common Mistakes
- Bungee PO
- Passive PO
- Unsustainable pace
- Smoke and mirrors
- Reporting up the sprint burndown