A post-class brochure from one of my Certified Scrum Product Owner trainings in 2016.

1. Agile product management
With scrum
Alexey Krivitsky, CST
www.agiletrainings.eu

2. Agile Coach
developer, scrum master,
scrum trainer, free-rider
Alexey KRIVITSKY
www.agiletrainings.eu
1980 – present
Kiev – Hamburg

11. Part 1
Lean
Agile
scrum

13. Customer collaboration over
contract negotiation

15. 1930-1950
Taiichi Ohno
Deming
Shewhart

17. Lean classifies 8 Wastes
“Tim Woods”
Transportation moving parts, people, informa7on
Inventory storing parts, documen7ng
Motion bending, turning, reaching, li=ing
Waiting for parts, info, equipment, tools
Over production making more than is immediately required
Over processing 7ghter tolerances and more efforts than necessary
Defects rework, scrap, incorrect documenta7on
Skills under u7lizing capabili7es, inadequate trainings

18. WHAT ARE THE TOP WASTES
IN SOFTWARE DEVELOPMENT?

19. The CHAOS Report
hDp://www.standishgroup.com/Reports2015

20. scrum is a
product development framework
scrum connects product people with
development teams.
Scrum helps learn fast by inspecting and
adapting product and process.
Scrum exposes your process inefficiencies
– it is like a mirror.

21. Which Terms from the List
Are Not Part of Scrum?
User Stories
Velocity Metric
Grooming Meetings
Continuous Integration
Automated Testing
Monthly Releases
Visual Task Boards
Story Points

22. Scrum 101
Scrum Roles:
1. Product Owner “P.O.”
2. Development Team
3. ScrumMaster
Scrum Artifacts:
1. Product Backlog (PBL)
2. Sprint Backlog
3. POTENTIALLY SHIPPABLE Product Increment “PSPI”
Scrum Ceremonies:
1. Sprint
2. Sprint Planning
3. Daily Scrum
4. Sprint Review
5. Sprint Retrospective

23. dual track scrum

25. Part 2
PRODUCT OWNER

26. Product Owner
Waiter or doctor?

27. http://www.agileproductdesign.com (Jeff Patton)
Shared documents ≠ shared understanding
“I’m glad we all agree”

28. http://www.agileproductdesign.com (Jeff Patton)
Help externalize ideas and see differences
“Oh…”

29. http://www.agileproductdesign.com (Jeff Patton)
Help to have regular discussions
“Ah ha!”

30. http://www.agileproductdesign.com (Jeff Patton)
That will lead ultimately to shared understanding
“I’m glad we all agree then”

32. Defining Product Owner
A Product Owner is not a new name for a
tradi7onal project manager who delivers a
scope and date contract of work. Rather, (s)he
has the independent authority to choose and
change content, release dates, priori7es, vision,
etc.
Of course, (s)he collaborates with
stakeholders and teams, but a real P.O.
has the final decision-making authority.

34. How Many Product Owners do you need?
A company develops a web-shop with services
like: a catalog, user profiles, email subscrip7ons,
persistent shopping cart, payments and B2B-
integra7on for partner shops.
How many products do you iden7fy?
How many Product Backlogs will you have?
How many Product Owners will you need?

35. Overall Product Backlog
for Web-Shop Scrum Teams Single Product Increment
one sprint
Scrum @SCALE:
One product owner per a product
one demo
one deployment environment
one codebase, one repo, one master
one set of tests, one con7nuous integra7on

36. Visit less.works
Large-scale scrum

38. Part 3
LEAN STARTUP

39. Minimize building
Maximize learning.

40. types of hypothesis
1. Problem hypothesis
We assume there a problem.
2. User hypothesis
We assume these people have this problem.
3. Solu6on hypothesis
We assume our solu7on will solve it.
4. Growth hypothesis
We assume there are enough users.

41. Pivot examples
1. Odeo began as a network where people could find and
subscribe to podcasts.
2. This company actually began as an online role-playing game
called Game Neverending, where users would travel around
a digital map, interact with other users and buy, sell and
build items.
3. It was developed by a company called Confinity in 1999 to
allow people to “beam” payments from their PDA.
4. In 2007 a website called The Point was created which was a
“social good” fundraising site that ran on a “7pping point”
system, where a cause would only receive funding once the
pledged dona7ons reached a certain number.

42. What will you do when you learn your
hypothesis were wrong?
Agile makes Changing your mind legal.

43. Part 4
Knowing your users

44. Design thinking

45. Knowing your users
1. Demographics
who are they?
2. Values, Goals, Behaviors
what do they want to achieve?
how do they do their work now?
3. Needs, Frustra6ons, Problems
what is their pain?

47. User Interviews
PREPARING
1. Know what you want to learn
2. Target the right users
3. Look for facts, not opinions
4. Poll enough users to get generalized informa7on

48. User Interviews
RUNNING
1. Ask open-ended ques7ons
2. Ask for examples
3. Ask ‘why’ many 7mes
4. Be open to learn unexpected things

50. Listen to what your users want.
But offer them what they need.

51. Part 5
Maximizing impact

53. Impact Mapping
1. WHY
which business impacts are we to reach?
2. WHO
who are the actors to help us reach the impact?
3. HOW
how the actors will do it?
4. WHAT
what exactly will we do?

54. Part 6
Defining mvp

55. how fast can you learn?
Do you need to build all product to see if it is valuable and
usable?
Can you build a part of it to validate your key
assumptions?
Can you build bare minimum to learn?
Can you not build it and still learn?

56. Build an MVP
1. Explainer Video
2. Landing Page
3. Wizard of Oz
4. Concierge
5. Fund Raising
6. Single Featured
hDp://7nyurl.com/mvp-ideas
hDp://scalemybusiness.com/the-ul7mate-guide-to-minimum-viable-products/

61. Part 7
Designing solutions

62. How and where do you keep
your product ideas?
Say “yap” if you keep them in the Product
Backlog.
Say “whoopsi” if you Product Backlog has
more than 100 items.
Say “yaks” if you need to use some sort of
epics/themes/lables in your backlog tool to
group the items so that they can be found?

63. So how and where do great POs
keep the product ideas so that
the storage doesn’t turn
into a junk yard?

64. So how and where do great POs
keep the product ideas so that
inventory management costs
are kept low?

66. USER ACTIVITIES
(BACKBONE)
USER TASKS
(WALKING SKELETON)
time
priorities
RELEASES
MMP

67. Ac7vi7es:
What the user wants to do?
User Tasks:
How does (s)he do it? Steps?
User Stories:
What are the op7ons of
performing the task?
The simplest?
More elaborated?
Even more?

68. Story Mapping
A mul6-dimensional Product Backlog that keeps
the mul6-dimensional nature of a Product
Backlog intact.

73. Scrum Inception
The bare minimum to start scrum
1. Common understanding of Scrum roles
2. Team arrangements
3. Initial Product Visioning
4. User personas, user/market insights
5. Story mapping
6. Initial Release Planning: MVP, next releases
7. Defining Done
8. User Story Writing Workshops
(minimum: Product Backlog for the 1st sprint)
9. Backlog refinement
10. Sprint Planning
Product
Visioning
Release
Planning
Sprinting
Process
Agreements

74. Part 8
Backlog
management

75. USER STORY FORMAT
As a <role>
I want <action>
So that <outcome>

76. 3Cs with user stories
Card
Conversation
Confirmation

78. Product Backlog Iceberg
Priority2-3 Sprints
Release
Next
Releases
Refined User Stories
Non-Refined User Stories
Epics

79. Types of PBIs
VISIBLE
FEATURE
VISIBLE
DEFECT
HIDDEN
ARCHITECTURAL
FEATURE
TECHNICAL
DEBT
Posi7ve Value
Visible Invisible
Nega7ve Value

80. Backlog Management BUGS
1. Build quality IN – avoid bugs (lean thinking)
2. Avoid bug inventories. Introduce limits (<50)
3. Legacy systems - ‘Clean up’ sprints
4. Zero-bug policy: kill’em before they grow

81. MIXING WORK IN PRODUCT BACKLOG
HIDDEN
TECHNICAL
DEPT
VISIBLE
FEATURE
HIDDEN
ARCHITECT.
IMPROVEMENT
VISIBLE
DEFECT

82. PRODUCT BACKLOG SHOULD BE DEEP
Detailed Appropriately
Estimated
Emergent
Prioritized

83. Prioritization Techniques

85. Prioritization Techniques
1. Rela7ve Ranking
2. Buy a Feature
3. Kano Weigh7ng

86. Stakeholder Classification
IMPORTANT
keep sa7sfied
INFLUENCE
INTEREST
OTHERS
monitor
KEY PLAYERS
manage closely
AFFECTED
keep informed

87. Prioritization
requires
Scrutiny

88. Stakeholders “Buying” Features
Features Price Tag
(complexity*10)
Stakeholder A
(50 dollars)
Stakeholder B
(50 dollars)
Stakeholder C
(70 dollars)
Feature A 100 25 25 50
Feature B 20
Feature C 50 25 25
Feature D 100
Feature E 50
Feature F 20 20

89. Relative Ranking
Features A
Rela6ve Biz Value
(1-Lo, 10-Hi)
B
Rela6ve Complexity
(1-Lo, 10-Hi)
C
Rela6ve Penalty
(1-Lo, 10-Hi)
Rank
A / B * C
Feature A 10 1 1 10
Feature B 1 1 1 1
Feature C 5 2 1 2.5
Feature D 1 8 10 8
Feature E 8 8 5 5

90. Find Exciters, Linear, and Mandatory
Features of an iPhone

91. How do you
feel without
Feature-X?
How do you feel with
Feature-X?
GOOD OK BAD
GOOD
OK
BAD
Kano Weighting
EXCITER
LINEAR MANDATORY

92. Mixing up a Release
All from
Mandatory
1+ Exciter
Key
Liners

94. Product Backlog Refinement
Item
size
Level of details
LARGE &
UNREFINED
SMALL &
UNREFINED
CLEAR, TESTABLE
& FEASIBLE
© Roman Pichler
1. ESTIMATE
2. SPLIT 3. REFINE

95. PRODUCT BACKLOG REFINEMENT
IS THE PBI 1/10 to 1/6
OF TEAM’S VELOCITY?
SPLIT IT
REFINE IT NEXT PBI
NO
IS THE PBI CLEAR, FEASIBLE
AND TESTABLE?
NO
YES
YES

97. DEFINITION OF READY
An agreement within a Scrum team on what a
good PBI is - when is it ready for Sprint Planning.
• How to demo is clear
• Discussed with all team members
• Value is clear
• Small enough (es7mated)
• Detailed enough
• Can be started next sprint
• All inputs provided
• No blocking issues
• …
• How to measure user sa7sfac7on
• How to roll out and roll back

98. How to Split Backlog?
You are adding payment capabili7es to a web-shop.
Your teams iden7fied that you’ll need a database,
valida7on logic, integra7on with several APIs, build a UI.
Your teams want to create the following product backlog
items:
1. Create database to store transac7ons
2. Integrate with APIs
3. Transac7on valida7on
4. Develop UI for payment processing
What would you say?

99. ?
Overall Product Backlog Scrum Teams
Payment DB
Payment API
Payment
Valida7on
Payment UI
Technical Split
one sprint

100. DATABASE
BUSINESS LOGIC
API
FRONT-END
Component Teams

101. Overall Product Backlog Scrum Teams
Payment DB
Payment API
Payment
Valida7on
Payment UI
Technical Split
one sprint

102. Overall Product Backlog Scrum Teams
Payment DB
Payment API
Payment
Valida7on
Payment UI
Technical Split
one sprint one more sprint one more sprint

103. INSTEAD Split BY BUSINESS VALUE
Payment
Payment with
Visa
Payment with
MasterCard
Payment with
PayPal
User is informed if
card data is not OK
User is taken to
success page
User is taken to
retry page
User can store his
card data Too big for a sprint S7ll too big for a sprint

104. Overall Product Backlog Development Teams
Payment with
Visa
Payment with
MasterCard
Confirma7on
Email
Payment with
PayPal
SCRUM @SCALE
v1
1 PO
Common Sprint
Single PSPI

105. Split these stories
1. As a par7cipant I can register to the course using my
email, Facebook or LinkedIn accounts.
2. As a par7cipant I can search for trainings for next
year by topic and loca7on so that I create a year-long
training plan.
3. As a trainer I want to manage class par7cipants.
4. As a trainer I need to upload par7cipant list so that
they receive class materials as well as photos and links
to books and ar7cles.

106. Acceptance tests in bdd
GIVEN …
WHEN …
THEN …

107. Part 9
Collaborating with
a development team

109. In a Head of a Product Owner
You have split all the features into stories,
es7mated them with the teams, start measuring
velocity… and the data tells that you can’t do it
by the deadline.
What do you do?
A) Ignore the data and con7nue working
B) Try to shi= the deadline
C) Add people to the project
D) Make people work harder

110. Tracking Release Progress
Time (sprints)
Amount
of work
(points)
rate of backlog change
when
you
will
release
amount
of work
remaining

111. Managing Release Scope
Time (sprints)
Amount
of work
(points)
Deadline
MOVE THIS MANY
POINTS TO
NEXT RELEASE

112. Ingredients of Self-Organization
1. High Alignment
our goal is …
2. Clear Constraints
Here are some boundaries to follow …
3. High Autonomy
go and figure out how …

113. Alignment and Autonomy
micro-management leadership
chaos
chaos

115. SPRINT PLANNING 101
Commitment-based PlanningPARTONE
PARTTWO
INITIAL SPRINT GOAL
PRESENTED
PLANNED CAPACITY
DISCUSSED
TOP PRODUCT BACKLOG
ITEMS PRESENTED
PBI REVIEWED ONE BY ONE
NEEDED REFINEMENT
HAPPENS
ITEM ADDED TO SPRINT
PLAN
CONTINUE UNTIL TEAM
SAYS “ENOUGH”
SPRINT GOAL GETS ADJUSTED

116. Sprint Is Not Mini-Waterfalls
analyze
design
test
code
Sprint Sprint Sprint Sprint

117. SCRUM IS NOT A SERIES OF MINI WATERFALLS
Feature A Feature B
PLANNED:
A,B,C,D
DONE:
nothing
DESIGN
PROTO
MORE CODING
TESTING
Sprint done wrong
CODING
Feature D Feature C
(next sprint)
PLANNED:
A,B,C,D
DONE
A,B,D
Sprint done right
Discussion Point
[PO + Dev Team]

118. Done. or Done-Done-Done?
Feature A Feature B Feature D
COOL: A,B AND D ARE DONE!
CAN WE DEPLOY THEM NOW?
(poker face)
OK.. SO WHAT’S LEFT?
1.
2.
…
10.

119. Agile Coach
developer, scrum master,
scrum trainer, free-rider
Alexey KRIVITSKY
www.agiletrainings.eu
1980 – present
Kiev – Hamburg