Backlog

Stake-holders

DevTeam

PO

Product Vision

AwesomeProduct

Product OwnersSkills for successful

Co r inna Ba ldau f

3

5

39

69

99

117

Role of the PO

Agile & Scrum

Product Management

Facilitation

Beyond Scrum About

As a Product Owner you have chosen a challenging and

worthy path! This book will make the trip smoother by

pointing out important waypoints. In base camp you

find what you need to know about Agile & Scrum itself,

before we head out to cover topics from Product

Management. You’ll be much more effective as a PO if

you can help people talk to each other and collaborate.

That’s why we cover Facilitation next. We end our jour-

ney on a mountain top looking at useful concepts from

surrounding areas.

May you have an inspiring journey!

All the best, Corinna Baldauf

Welcome!

Product Owners have a very important role: They maxi-mize product value for the customers and the business. This requires many trade-offs, clear communication and an unwavering vision for the product. Sounds like a tall order? It is, but you can master it! This book is here to help you hit the ground running.

More Information

· Henrik Kniberg’s excellent video “Agile Product Ownership in a Nutshell”: https://www.youtube.com/watch?v=502ILHjX9EE· The official Scrum Guide: http://www.scrumguides.org/scrum-guide.html#team-po

Role of the PO

Content by Corinna Baldauf, inspired by Henrik Kniberg

Designed by Wall-Skills.com - Level up, 1 page at a time

PO

sele

cts &

prioritize

s

ÄDev

Team¿

estimates effo

rtÄStake-holders

Estimated

Business Value

request features

Requirements

Eliciting Features

Facilitating

FeaturesTechnical Feasibility

Cost

Time

Effort

PO

Product Owners are crucial for product

success as they decide what to build and

what not to build. These decisions are

based on constant dialogue with stake

holders and dev team. The PO is the

sole person managing the Product

Backlog and ordering it to maximize value. They make sure the Backlog is

visible and understood. For the PO to

succeed, the entire organization must

respect his or her decisions.

The Role of the

Product Owner

Product Vision

AwesomeProduct

PO projects releases

PO maintains

BacklogR

efin

ed

Sto

rie

sC

oa

rse

Ep

ics

As a <role> I want <goal>

so that <benefit>

User Story

Build the right thing

Build

the thin

g right

Magic

Build it fast

Co r inna Ba ldau f

Agile & Scrum

Agile Software Development is changing the IT world.

The process framework Scrum is one way to do agile. It

is especially popular, extending its reach even beyond

tech companies.

Agile & Scrum

· Agile Manifesto

· Agile Principles

· Agile Mindset

· Agile “Laws”

· Scrum Roles

· Scrum Events

· Scrum Artifacts

· Emotions during Change

· SCARF Model

Content

· Agile Adoption Patterns

· Retrospectives

· Sprint Goal

· Definition of Done

· Definition of Ready

· User Stories

· INVEST

· Tuckman’s Team Stages

· Technical Self-Assessment

“Kanban and Scrum - Making the most of both”

by Henrik Kniberg & Mattias Skarin is by far my favourite

book for beginners. A nice, short read and actionable.

http://www.infoq.com/minibooks/kanban-scrum-minibook

More Information

Sadly some teams manage to follow Scrum rules with-out really living any of the agile values. But agile is a way of thinking as well as doing. “Being agile” contains a cer-tain outlook onto the world. The 1-pager describes the difference between the traditional and the agile mindset in a few areas.

Agile Mindset

There is a less pretty version of this 1-pager that shows more scales: http://finding-marbles.com/2011/12/10/agile-mindset-examples/

More Information

Content by Corinna Baldauf - http://finding-marbles.com

Designed by Wall-Skills.com - Knowledge on 1 page

There are a couple of postulated “laws” that agilists gen-erally believe in and quote frequntly. These laws / ob-servations contribute to the agile mindset.

Agile Laws

Content & Design by Corinna Baldauf - finding-marbles.com

Check out Wall-Skills.com for other printable 1-pagers!

Little’s Law

Cycle Time = Work in Progress

Throughput

If you work on twice as many

things in parallel, it’ll take twice

as long.

Conway’s Law

The interface structure of a software

system will reflect the social structure

of the organization(s) that produced it

Communication and power structures surface in a

company’s products - causing many a usability problem.

Humphrey’s LawThe user will never know what they

want until after the system is in pro-

duction (maybe not even then)

Ergo short iterations and review meetings.

Parkinson’s LawWork expands so as to fill

the time available for its

completion

Law of PropinquityThe probability of two people

communicating is inversely

proportional to the distance

between them

Law of the InstrumentIf all you have is a hammer, everything

looks like a nail

Goodhart’s LawWhen a measure becomes

a target, it ceases to be a

good measure

Metrics can be gamed.

Dude’s Law

Project Value = Why

How

If you don’t have a good reason

for the project, it doesn’t matter

how well you do it.

in

Software Development

Common Laws Agile & Lean

A Sprint Goal allows the dev team to make good tradeoffs even if they can’t check back with the PO.

Sprint Goal

· Roman Pichler created a Sprint Goal Template: http://www.romanpichler.com/tools/sprint-goal-template/

More Information

Content by Corinna Baldauf - http://finding-marbles.com

Designed by Wall-Skills.com - Spread Knowledge with 1-Pagers

What is a sprint goal?

Each sprint should have an explicit sprint goal, e.g. written out across the Scrum board. Think of the goal as the elevator pitch of a sprint. During planning a Scrum team commits to the sprint goal, not a bunch of stories.

Who sets the goal?

The product owner can choose the goal beforehand to help her order the backlog according to the goal. Alternatively the whole team can phrase the goal at the end of planning, when they know which stories will be part of the sprint.

Examples of good and bad goals

· Bad: “Complete all 4 stories we pulled” Doesn’t add information to enable good team decisions

· Bad: “Improve the dubbledigook widget” Completely fuzzy. How can you to tell when / if you’re done?

· Better (i.e. enabling and measurable): “Customers can pay with bank transfer” “Time to first byte on the landing page is less than 0.7s” “Increase conversion rate by 10%”.

Why set one?

The goal helps the team focus and make good trade-offs, even when the product owner is not available to help. A team might reach the sprint goal even if they can’t finish all stories.

źŻ

Co r inna Ba ldau f

Product Management1-Pagers about

The skills in this chapter are specific for the PO role. They cover agile concepts, such as User Stories as well as ideas from traditional Product Management and User Experience.

Product Management

· Saying “No”

· User Stories

· INVEST

· Story Mapping

· Minimum Viable Product

· Design the Box

· Elevator Pitch Template

Content

· Kano Model

· Planning Origami

· Hallway Usability Tests

· Design Studio

· 3 Horizons

· Pioneers, Settlers,

Town Planners

· PO Coaching Cards

In agile environments you reduce big upfront design, because you know that customer requirements will change. Capturing requirements as User Stories is the most common approach. User stories are short and easy to use.

Jeff Patton says they are called stories because we’re meant to have a conversation – tell a story – about them.

User Stories

Capture requirements with User Stories - Consise and easy to use!

User Stories

As a the results table widget I want my columns to be sortable so that customers can sort (Duh!).

As a flight booker I want to order search results by price so that I can find a cheap flight.

Content by Corinna Baldauf - http://finding-marbles.com

Designed by Wall-Skills.com - Spread Knowledge with 1-Pagers

As a <role> I want <goal>

so that <benefit>

Classic format

In order to <benefit> as a <role> I want <goal>

Focus on benefit

Capture requirements as User Stories - Concise and easy to use!User Stories

In agile environments you reduce big upfront design, because you know that customer requirements will change. Capturing requirements as User Stories is the most common approach.

A User Story has 3 components (3Cs): The physical Card contains title and description. It’s a reminder to have a Conversation to create a shared understanding between everyone involved. You discuss what is really needed and agree on acceptance criteria to Confirm that the team achieved the benefit.

A User Story contains:

· The Role - Who wants something. Ideally a customer (persona).

· The Goal - What does the user want to do?

· The Benefit - Why the customer wants this. What does she want to achieve? This is the most important part of the story, because you may discover that there’s a better way to reach the benefit.

Example stories for a CMS:

· Bad: “As the database I want a field ‘status’ so that I can store if a post is a draft or published” Databases can’t want anything. What’s the benefit for customers?

· Good: “As an author I want to save posts as drafts so that I can finish them later”

User Stories are the de-facto standard of capturing feature wishes in agile teams. Even though the product owner plays a major role, honing the stories is a team effort. A good user story fulfills the INVEST criteria.

New teams often struggle with tha “small” part. Check out Richard Lawrence’s excellent article on ways to split user stories: http://www.agileforall.com/2009/10/patterns-for- splitting-user-stories/

More Information

INVEST

INV

ndependent

The accronym INVEST was coined by Bill Wake

Designed by Wall-Skills.com - Spread knowledge with 1-pagers

Independent stories can be freely re-ordered in the product backlog. Sometimes you can’t get rid of an order dependancy but it should be an exception.

Good User Stories are INVEST

EST

egotiable / NegotiatedA user story is the reminder to have a conversation. In that conversa-tion the team negotiates the concrete solution, the ”I want” part. The story may be enhanced or rewritten.

aluable / VerticalEach story adds something useful for the end user / customer - the “so that” part. This leads to vertical increments: E.g. a working slice of front end, scripts & DB, instead of a finished DB without front end.

stimableYou need a rough effort estimate to guestimate ROI and order the backlog. If you can’t estimate, you need to a) break the story into pieces or b) better understand what value it’s meant to add or c) explore unknown tech in a time-boxed research spike.

mallSmall stories are easier to estimate and test and hide fewer misun-derstandings. “Small” can be 1 day in a web shop or 3 person-weeks for a medical product. At the very least, the team must be able to finish a story (“done done”) in 1 iteration.

estableIt must be possible to write a test (at least in theory) for each story. Otherwise, how will you confirm that the story is done? Sometimes test cases are given as acceptance criteria. If you can’t think of a test, the story is probably to fuzzy.

Agile teams usually capture requirements in the format “As a <role> I want <solution> so that <value>”. The whole team - business and development people together - improve stories by making them:

Story Mapping as a fantastic method to plan a product

(or feature), sort user stories into releases and to serve

as a backlog on steroids during development.

Story Mapping

More Information

Find out more in Jeff Patton’s book “User Story

Mapping” or in his 2008 blog post that started it all:

http://jpattonassociates.com/the-new-backlog/

Find out more in Jeff Patton’s book “User Story Mapping”

Designed by Wall-Skills.com - Level up, 1 page at a time

To create a map start with the overarching activities, the “Backbone”,. In the row below the backbone you list user tasks. Tasks have a column of related sub tasks and refinining user stories below them.

Once your map is “finished”, walk a variety of people through it and refine. You typically build the software from left to right, starting with the “Walking Skeleton”.

User Story Mapping

CustomizeCoffee Order

Timeline - What are your customers doing?

Customers can get customized coffee beans

User Activities

High Level Goal

Nec

essa

ryO

pti

onal

Choose beans

Choose syrup

Enteraddress Pay

Login

Successpage

Pay with

Paypal

Pay withCC

Vali-date

CreateAccount

Errorpage

Choose1 bean

Choose 1 syrup

Choose 2nd

Choose 2nd

User Tasks

Walking Skeleton

MVP

Release 2

Sub Tasks(User Stories)

Backbone

When working with stories in a backlog, it is easy to get lost in details, making it hard to prioritize. A better solution might be a User Story Map - Essentially a 2-dimensional backlog that captures the big picture of user activities and makes it easy to plan out what level of functionality needs to be in which release. Here’s an example:

Meeting Checklist Fancier

Flipcharts

Design the Box

Open Space

Lean Coffee

T I N G

IRW

Co r inna Ba ldau f

Facilitation &Communication

Good facilitators support a discussion with structure. They reign people in that are rambling on and encour-age others to say what needs to be said to bring import-ant matters out into the open.

The 1-pagers in this book cover various techniques to structure discussions and meetings.

Facilitation

· Ways to Vote

· Open Space

· Lean Coffee

· SMART Criteria

· Brainstorming

· Meeting Checklist

· Silence a Room

Content

· Hand Signals

· Powerful Questions

· Solution Focus

· 4 Sides of a Message

· Glasl’s Stages of Conflict

· Fancier Sketchnotes

· Writing Well

Check out the “Facilitator's Guide to Participatory Decision-Making” by Sam Kaner

More Information

A big part of the magic of Agile Software Development are self-organizing teams. These teams take a lot of de-cisions themselves that used to taken by managers. When first trying to work this way, it can be difficult to agree after a group discussion. Here are some basic ways to vote to help teams take decisions.

Ways to Vote

Content from Corinna Baldauf - Finding-Marbles.com

Designed by Wall-Skills.com - Knowledge on 1 page

Everybody votes at the same time by

showing a thumb up, horizontal or down. Thumb up shows support, thumb

to the side means "I'll support whatever the majority wants" and thumb

down means that you want to speak.Beware of lots of horizontal thumbs.

Support is lukewarm at best.

Gauge the support for one proposal

Roman Vote

In a discussion the participants seem to have

reached consensus yet it's not explicit“Was that a decision?”

You don't always need a vote. In unclear

situations, encourage everyone to loudly ask

“Was that a decision?”. This question often gets

enough silent people to voice a “Yes” so that people

know that they indeed just took a decision. If they object,

people are forced to speak up.

All participants get the same number of

votes to split and distribute on the options however they like. Fewer votes

mean faster counting. 3 votes per person is a popular number. In this case

1:1:1, 1:2 and 3 votes for the same topic are all valid.

In the name-coining form of Dot Voting the facilitator hands out stick-on

dots to the participants. 1 dot per vote. If you're not concerned about

someone manipulating the votes, you can also use X's, drawn with big

markers. That way it also works on whiteboards.

You’ve got a list of options and want to pick the top ones fast

Dot Voting

In agile, self-organizing teams often take decisions for them-

selves instead of relying on managers. This can call for votes to

settle a discussion. Check out these basic ways to vote!

Ways to Vote

Open Spaces are a kind of unconference, i.e. an alterna-

tive to a “normal” conference. An Open Space has no

agenda prior to the gathering. The participants create

the agenda adhoc at the beginning of the unconference.

Open Space

· Corinna’s company holds an internal Open Space every

other Friday. It does wonders to spread knowledge:

http://finding-marbles.com/2015/09/03/

thank-god-its-open-friday-faq/

More Information

Open Space Technology was developed by Harrison Owen

Designed by Wall-Skills.com - Spread Knowledge with 1-Pagers

Room A Room B

10am

11am

1pm

Law of two FeetIf at any time during our time together you find your-

self in any situation where you are neither learning nor contributing, use your

two feet, go someplace else.

Typical Flow of an Open SpaceIn the beginning a facilitator reads out the theme of this particular Open

Space, followed by the general Principles and the Law.Then the floor opens for everyone to briefly introduce a topic they want

to talk about. This session topic can be anything that fits within the theme. They then place their session into a time slot and room on a big

bulletin board. At the set time and space everyone interested in the topic shows up to discuss it. The original suggester has to take notes that are

made available to all Open Space participants afterwards.

1. Whoever comes is the right people

2. Whenever it starts is the right time3. Wherever it happens is the right place

4. Whatever happens is the only thing that could have happened5. When it's over, it's over

Guiding Principles

You don’t need 50 people and the CEO in your discussion group to get great results

No need to stick to conference rooms. The lounge is great, too

Even if there are time slots to help organize you can ignore these. Finish early or overrun depending on the flow of the discussion

What part of a conference is most interesting and valuable to you? If it’s the discussions during breaks and informal evening gatherings, you are not alone. Open Space Technology enables participant-driven gatherings with lively discussions and without prior agenda.

Space

Open

Lean Coffee because it is an extremely versatile method that can turn a chaotic meeting into a structured discus-sion that covers the most important topics and invites participation. They are the Open Space’s little sister. Try it, it’s close to magic!

Lean Coffee

· LeanCoffee.org

More Information

Method described at LeanCoffee.org

Designed by Wall-Skills.com - Spread Knowledge with 1-Pagers

Lean CoffeeStructure agenda-less meetings by jointly creating an agenda

with the most popular topics - with minimal overhead.

Optional: To prevent endless discussion of a topic that only a mi-nority remains interested in, you can set a timer at the beginning of each topic. When the alarm sounds everybody gives a thumbs up or down. If most thumbs are up, the topic gets another 5 min-utes. Otherwise start with the next topic.

Reorder the topics according to the votes and start with the highest ranked one.

XP現地現物Time

Nu

mb

er o

f Ta

sks

Lead Time

Cycle Time

Bac

klog Still

To

Do

In P

rogr

ess

Next

A

B

C

D

E

Tasks Dev QA Done

Deploy

3 2

H

I

F

G

Co r inna Ba ldau f

Beyond Scrum1-Pagers that go

Right now, Scrum is the dominant software develop-ment process. Knowing about approaches outside of Scrum will make you a more well-rounded Product Owner, someone who is able to pull ideas from many different sources.

Beyond Scrum

· Value Stream Mapping· Kanban· Cumulative Flow· Japanese Terms in Lean

Content

· Lean Startup Principles· DevOps· Cognitive Bias· Master Any Skill

Value Stream Mapping is an amazing technique from Lean Management to analyze and improve how you deliver value to your customers

Value Streams

Example by Jay Arthur - youtu.be/3mcMwlgUFjU

Designed by Wall-Skills.com - Spread Knowledge with 1-Pagers

Log Eval Valid? ScheduleExam TreatDia-

gnose7d 1 d

Log Eval Re-search Valid? Schedule

Exam TreatDia-gnose25d 120d 7d 1 d

Value Stream Mapping

Value Stream Mapping (VSM) is a tool from Lean Management to analyze the flow of materials and information to deliver value to customers. “Value” is typically a product or a service.

Could you deliver more efficiently?

Example from a medical facility

How many steps of the “stream” in your company really benefit the cus-tomer and what is just busywork? How much time do you and your col-leagues spend adding value? How much is waste, i.e. things customers don’t care about such as waiting times, internal reports, etc.?

Use VSMs to learn how you can deliver what customers pay you for faster.

The staff recognized that they spend only 7 hours per patient in val-ue-adding activities, i.e. activities that advance the patient’s treatment. The other ~150 days are waiting time, i.e. waste.

It also became apparent that speeding up, e.g. “Diagnose” would not help them. If they wanted to make a noticable reduction they had to tackle the 120 days delay between “Eval” and “Research”.

In the end, they realized that they didn’t need all the steps. They designed and implemented a new VSM that cut their patients waiting time down to 30 days max:

Patients were dissatisfied because it took more than 3 months to get treatment. The medical facility’s VSM:

Create a VSM for your company!

All you need is a pen, sticky notes and 30 minutes time.

Corinna Baldauf has filled every Scrum role there is and then some. She likes to create resources and is interest-ed in lean, agile, systems thinking, communication, lead-ership & UX.

The 1-pagers in this book appeared on Wall-Skills.com, a project by Corinna Baldauf and Roland Wolters. Wall-Skills.com fosters condensed, casual education. The topics range from Agile to DevOps to Soft Skills.

Got a question or suggestion? Email corinna@finding-marbles.com or tweet to @findingmarbles.

About

My sincere thanks go to my Wall-Skills partner Roland Wolters, to my husband Tobias, and to my family, who instilled in me the deep wish to pass on whatever knowledge I acquire.

Acknowledgements