Cue cards Product Owner Fundamentals - AgileMark/AM GitHub Wiki

Intro MJ + JB

  • Introduce ourselves and the A@S programme.
  • Show the course objectives slide.
  • Mention that not everyone on the course is a PO, and that's ok, as:
    • there will be general agile learnings throughout the course too.
    • also its worth people who are not POs knowing more about the PO role.
  • Ask attendees to say a bit about themselves and say if there is anything in particular they'd like to get out of the course. For people who are POs or may become POs, ask them to give some background about what their current role is, outside of being a PO - i.e. what are they doing when they are not being a PO (this might reveal some conflict between what they do now, and what they should do as a PO, for instance).

Intro to Product Owner exercise

  • Our overview of Product Owner role

    • Overview of the PO role at SG
    • Lyssa Adkins' stuff: daily decision maker, vision keeper, business value driver, heat shield?
    • What things could you be involved in as a PO?
    • Anti patterns
    • One key thing to emphasise is that there is a partnership between the PO and the team. It's not a case of the business telling ITEC what to do.

  • Product Ownership in a nutshell video (Stop video at 11:28 to truncate off the velocity bit) (Business value driver, Vision keeper)

  • Two weeks timeline in the life of a Product Owner (Daily decision maker, Heat shield) MJ

  • Mon

    • Stand up

  • Tue

    • Stand up
    • Review
    • Retro

  • Wed

    • Stand up
    • Planning

  • Thur

    • Stand up
    • Epic board walk

  • Fri

    • Stand up
    • Refinement (Story mapping)

  • Mon

    • Stand up

  • Tue

    • Stand up
    • Refinement (Example mapping)

  • Wed

    • Stand up

  • Thu

    • Stand up
    • Product Management Team Monthly
    • Epic board walk

  • Fri

    • Stand up
    • Refinement (Epic deep dive)

  • Also mention the typical PO/team interactions which don't have a definitive calendar event:

    • ad-hoc clarifications requested by the team e.g. acceptance criteria
    • demos and walkthroughs
    • ideas generated by the team towards potential new stories for the backlog (i.e. for a future sprint)

Exercise Backdrop MJ

  • Hand out backdrop material

Story mapping - JB

  • Introduce the concept:

    • A way of breaking down big pieces of work in a visual collaborative way, identifying stories

  • Break into two groups to perform the exercise - MJ + JB (Business value driver, Daily decision maker, Vision keeper)

  • Bring the two groups together to review the exercise

    • Shared understanding
    • Shared picture
    • multiple sessions
    • small groups
    • revisit often
    • visible low fidelity output lends itself to change

MVP (story mapping) - JB (Business value driver, Daily decision maker)

  • Introduce the concept:

    • MVP stands for Minimum Viable Product but ...
    • Don't get hung up on the Viable Product bit
    • its in everyone's interest, business included, to get quick feedback and adapt hence Minimum
    • Explain MVP is the minimum amount of work to get feedback ideally from customers but not necessarily
    • Use the personas to help to inform what to choose for the MVP
    • If in doubt leave it out

  • Break into two groups to perform the exercise

  • Bring the two groups together to review the exercise

    • When would you use story mapping?

Release plan (story mapping) - MJ (Business value driver, Vision keeper)

  • Again use the personas to help to inform the release slicing

  • Break into two groups to perform the exercise

  • Bring the two groups together to review the exercise

    • A release plan should not be set in stone
    • The further away releases are the more subject to change they are

Introduction to Product Management Team

  • We don't need to mention much (or anything) about chapters at the moment, unless it comes up in a question. If chapters do come up, we should say that they are secondary supporting structures, and one of many inputs in to the PMT (which is the sole funnel)

Initiative boardwalk

  • This is in Jira only at the moment [Insert URL here](Insert URL here)

Epic boardwalk JB + MJ (Business value driver, Daily decision maker)

  • This is a positive example - we don't do a positive and a negative example for the epic boardwalk (we do both for the daily stand-up board).
  • Things to talk about:
    • Explain that the boardwalk could typically be weekly
    • Physical board synced with JIRA board (not a big overhead to do this)
    • Visible process policies
    • Dates when cards move across columns
    • Cycle time and lead time
    • WIP limits
    • Sizes
    • Sparseness of card detail - placeholder for conversations
    • Use of colours to convey information

Epic deep-dive JB + MJ (Business value driver, Daily decision maker)

  • Use the basic list functionality epic
  • Show the value of collaborating in multiple conversations - our example shows things like architecture that didn't come out in the first conversation but did in a subsequent one
  • Importance of considering all the things and stakeholders on the epic A3 e.g. architecture - very useful to get architects involved at this stage. Same for Production - they would be involved in the discussions too, ensuring that their needs are captured at this early stage. Production and Architecture are important stakeholders in all epics.

Refinement

  • Backlog maintenance
  • What could a PO be involved in?

Sprint goal (Business value driver, Vision keeper)

  1. Introduce the notion of a sprint goal (a coherent goal for the next sprint), but don't explain why this is a good thing, yet.
  2. Split into small groups (can be the normal two groups, or groups of any size, even pairs) and come up with answers to the following:
  • What benefits could having a sprint goal bring?
  • What would be the downsides/limitations of not having a sprint goal?
  1. The groups share their answers with everyone, followed by a group discussion about the answers.
  2. We (the course presenters) present a summary of what we think the benefits are:
  • Encourages the team to be able to adapt during the sprint (to meet the goal), rather than feeling they have a fixed scope. i.e. it elevates the notion of a goal above the nebulous notion of "requirements"
  • Improves value delivery by improving focus and therefore flow
  • Provides a mechanism to ensure things without much value don't slip in (either before or during the sprint)
  • Promotes team cohesion - vehicle for collaboration. And actively discourages individual silo'ed work. Team spirit.

Backlog prioritisation exercise (Business value driver, Daily decision maker, Vision keeper)

These two items can be referred up to the PMT:

  • Part of a project, unrelated to the sprint goal. A project manager insists that the team spend time working on this project every sprint.
  • A senior stakeholder has asked for this ASAP. It will only deliver value in 5 month's time, even if delivered now. Estimate is 2 weeks

This one below would go to the PO, who would probably put it in the following sprint. Shouldn't be any need to involve the PMT, as it's only 2 days.

  • An application manager has gone straight to a team member and asked them to do something. 2 days work. Has some value but not related to the sprint goal.

The problem with flat backlogs

  • This is in Jira only at the moment
    • [Flat backlog](Insert URL 1 here)
    • [Non flat backlog](Insert URL 2 here)

https://www.jpattonassociates.com/the-new-backlog/

a flat product backlog is a laundry list of ‘stuff to do’ that will ultimately provide value to the customer. These actionable items are prioritised (top to bottom) in the order the value will be delivered. If a team is practicing Scrum the backlog is then split into future sprints to provide an indication of what will be delivered and when.

Cant see the wood for the trees. Big picture and overarching business value are both lost due to a muddy mess of disparate small things not pulled together. Typically prioritised in weird and wonderful ways because thee is too much to make sensible priority calls.

A flat backlog is a bag of context-free mulch.

How do you pick an item from a list, and deem it the thing that’s going to provide the most value to your customers, without that additional context?

Shortcomings of a Flat Product Backlog

  • The flat backlog makes it impossible to discover the ‘backbone’ of your product — the customers interaction experience with the product
  • Arranging user stories in the order they’ll be delivered doesn’t help a product manager explain to others what the system does?
  • The flat backlog provides no context or ‘big picture’ around the work a team is doing
  • A flat backlog makes it hard for the product manager to determine if they’ve identified the relevant user stories Release planning is difficult with a flat backlog. How do you prioritise what to build first in an endless laundry list?

Non Flat Product Backlogs

provides context for teams by answering the following questions:

Why are we building this? Who are we building this for? What value will the solution provide for the customer and when?

What A Non flat backlog Achieves that a Flat Product Backlog Can’t

  • Focus on Desired Customer Outcomes: rich visualisation enables identification and implementation of features based on customer outcomes
  • Prioritising Actions Based on Value to the Customer: Tying small things together to see where they have come from enables you to see and prioritise at a higher level to be able to achieve agility through the art of maximising the amount of work not done so you can go faster. Working smarter not harder.

Example mapping JB + MJ (Business value driver, Daily decision maker)

  • Use 2.2 Share this list with other people as the story for this exercise
  • Include t-shirt size (S, M or L) estimating the story
    • This demonstrates relative estimating
    • Use these three stories as reference examples for S, M and L:
      • Small: See my list items alphabetically
      • Medium: Add a photo to an item
      • Large: Watch a "how to" video

Possible Scenarios to use:

Use Persona Ben and Rose and think about splitting into 2 stories: IOS and android

  • As a busy home user I want to share my list with my partner so that I collaborate better so that we do not get mixed up

  • Given I open a list someone has shared with me when I open the list then I see the same items the first person input

    • Example data: Blah 1, blah 2, blah 3
    • Example data: list shared with no items

  • Given I share a list when my partner opens the app then they see the shared list in their list of lists

  • Can share with any contact in phones address book that has an email address

  • Bob cannot share with Sue because he only has her phone number and not her email

  • Bob can share with Rita because he has her email

  • Can share a magic link with anyone at all which will open the app or go to the app store

One example from a previous session was that share by email turned out not to be the right thing to do (at least initially) – instead if we assume that the other people already have the app then there’s no need for email to come into it – they’ll just get a notification via their app instead

Example mapping questions

  • Do we need to support other Oss or just IOS and Android?
  • Should we limit this story to just one operating system?

Example mapping wrap-up

  • Emphasise that example mapping is a great way for people involved in testing, analysis and development to collaborate together, nice and early in the process.
  • Also mention that the output of the example mapping is specifications that can act as single point of truth. They can be used as test scenarios which:
    • form the automated regression test scenarios
    • are the single point of truth for documentation purposes
    • allow developers to drive their development through these specifications:
      • Behaviour Driven Development (BDD)
      • Outside-in testing (developers can add lower level tests as they see fit)
  • So much more powerful than having the documentation and tests scattered between analysis documents, test team tests and developer tests
  • When would you use example mapping?

Planning (Business value driver, Daily decision maker, Vision keeper, Heat shield)

  • How to create a sprint goal - what is it and why is it important? (reinforce the PO as the Vision keeper)
  • Use the Enhanced List stories for this exercise
  • Stories taken into planning are (in order of priority):
    • See my list items by category (L)
    • See my list items alphabetically (S)
    • Arrange a list in the order I want it (M)
    • Add comments or notes to an item (L)
    • Auto-complete a list item from my history (M but will upsize to an L during the planning)
    • Auto-complete a list item from common grocery items (L)
    • See stats on a list (L)
  • When we upsize the auto-complete (from history item) to an L, we'll re-assess whether we can fit all the items into the sprint and decide that it and everything below it should be stretch items.

Stand up (Business value driver, Daily decision maker, Vision keeper, Heat shield)

  1. Role-play a bad stand-up:
  • Team lead asks for individual updates
  • Refer to items by their JIRA number, not their name
  • Playing with phone and not paying attention to others
  • One person be too vague or talk about things they did yesterday other than the work (yep still working on the same thing as yesterday and the day before and I won't finish it today either. Bob came up to me from the team opposite us and told me all about a in memory database he is working on that is really cool. He wants a bit of help from me so I am popping over after this to give him a hand)
  • One person interrupt the other
  1. Role-play a good stand-up:
  • Talk about the items in order of importance
    • Item in the expedite row
    • Start from the right of the board, not the left (we want to focus on finishing items over starting new items)
    • Items that are blocked
    • Items that have an imminent due-date
    • Look at the board as a whole, for things like:
      • too much work-in-progress
      • imbalances (too much in one column compared to others)
      • any other impediments to flow (e.g. no work ready for development) Reinforce the concept of the PO being a Heat shield as well as the PO.

TO think about:

  • Management intervention and/or other stakeholder intervention (Business value driver, Daily decision maker, Vision keeper, Heat shield)
  • Consultation with PMT/Sponsor (Business value driver, Daily decision maker, Vision keeper, Heat shield)
  • Product Owner not knowledgeable (Business value driver)
  • Production incident (Business value driver, Daily decision maker)

Demo

  • Put the demo phone into airplane mode

  • Plug the phone into the projector

  • Explain sharing was the sprint theme

  • Demo the enhanced list functionality in the lists app - mainly alphabetically ordering

    • Role play - product owner to notice that "Alphabetically inverse" was not asked for
    • Product owner to say that they would rather have the categorisation worked on instead
    • Don't build things that were not asked for
    • Product owner also to ask about the sharing icon (sharing is to be the theme of the next sprint)

  • Wrap up

    • Demo uncovered functionality not asked for
    • Working software allowed useful conversation about sharing functionality

Retro

  • Demo a negative and a positive retro based on the Lists mobile app theme.

  • Negative retro

    • Command and control - one of us directs the session "Ok guys, you committed to 25 points in the last planning, but you only did 5. That's completely unacceptable, I want you to make sure you deliver the points you've committed to. I don't mind if you work overtime if you have to."

  • Positive retro

    • Start by bringing in the actions from the previous retro:
      • Start having a sprint demo to stakeholders, every sprint
      • Agree and then document our definition of done and our definition of ready
      • Point out that we explicitly took the actions into the sprint as bona fide work items, which is why they were successfully completed
    • John and Mark to each write down one thing that went well, and one thing that didn't.
    • Mark
      • Not well: Enhanced list, because functionality was built that wasn't asked for
      • Went well: Demo of working software - useful feedback and conversations
    • John
      • Not well: Planning (took too long)
      • Went well: Team social

  • 2 votes each both vote for planning + one other

  • As planning had most votes, discuss it

  • 5 whys

    • Why did planning not go well?
      • Because it took too long
    • Why did it take too long?
      • Because not all stories had been elaborated beforehand
        • Also maybe compare it the previous planning, which went well because all stories had been elaborated
    • Why were all stories not elaborated beforehand?
      • We didn't have time specifically allocated to do it, and it was a very busy sprint

  • Action

    • Put a timeslot in the calendar for story mapping each day - don't need to rigidly adhere to this timeslot but should ensure that we don't forget it

  • Retro takeaways

    • Have regular retrospectives (i.e. every sprint), post-mortems after production incidents do not suffice (although have them too)
    • Anti patterns
      • Directing the session rather than facilitating

Wrap-up

  • Show the desired outcomes slide and ask if people feel the course has achieved that objective.
  • Ask everyone what, if anything, they would like to take away and start using with their team.
  • Emphasise that we the coaches are ready, willing and available to help with that or with anything at all
  • PO focused hints and tips