Pspo I Material

Front 1

definition for Agility

Back 1

Agility is the organizational state envisioned by moving to
Agile processes; a state of constant flux, evolution,
innovation, improvement and re-invention.
• Agility reflects an enterprise’s capability to respond to
challenges, to explore and change direction, to take
advantage of opportunities; to be quick and nimble.

Front 2

Purpose of the PSPO course

Back 2

Teaches how to wring more
value out of a product using
Agile software development
with the Scrum framework.
Understand the application of
Scrum theory and principles to
improve product management.

Front 3

why Agility is important

Back 3

Improved relationship with customers, regaining trust
• Flexibility to turn on a dime
• Improved productivity and quality
• Taking advantage of opportunities
• Early elimination of risk
• Early realization of value
• Always knowing where you are in a development/deployment cycle
• Easier to make changes
• Elimination of waste
• Lean products that reach market faster and are more targeted
• Increased Return on Investment
• Engaged, empowered workers
• Reduced Total Cost of Ownership

Front 4

Crafting the futures - Impact matrix (scenario planning)

Back 4

Front 5

Scenario planning

Back 5

1. Framing the challenge

2. Driving forces

3. Crafting the futures

4. Seeing the signposts

Front 6

Framing the challenge (Scenario planning)

Back 6

Understand your ‘why’
– Corporate, business unit or division strategies
• Frame your challenge
– What crisis are you facing?
– What changes will your market and industry go through impacting the
future of your product?
– The future is never a statistical extrapolation of the present.
• Underpin your challenge with data
– Trends, analyst reports, opinionated people
– Rising technologies and players
– Know your main assets and liabilities

Front 7

Seeing the Signposts (scenario planning)

Back 7

What are the signposts indicating in what
direction the future is unfolding?
• Keep monitoring the driving forces and
related events.
• Look for events that would indicate that a
particular scenario is emerging.
• Update the scenarios on a regular basis.
Once a year is typical.
Scenario
Planning is not
about precise
predictions, but
about flexibility
to respond.

Front 8

Product Vision

Back 8

Concise, visual and short Core concept

– Not a feature list
• Broad and engaging
• Less can be more, look for the minimal marketable product
– It’s faster, cheaper, improves cash flow, provides real feedback,
lowers risk
• To be kept relatively constant during the evolutionary process
– Expect a multiple releases Product Roadmap

• Scrum has no rules to describe the format
of a Vision.

Front 9

Geoffrey Moore Product vision template

Back 9

VISION TEMPLATE
• FOR <<main target
audience>
• WHO << need,
want>>
• THE
<<product>> IS A
<<succinct
description>>
• THAT WILL
<<the benefit>
• UNLIKE
<<competition or
current situation>
• OUR PRODUCT
<<competitive
advantage>>

Front 10

The Peanut Butter Manifesto

Back 10

Yahoo lacked the ability to be decisive and cohesive. Was spread too thin.

Demonstrates the need to have the ability to say NO

Front 11

Problems with KPIs

Back 11

KPIs Have Unintended Consequences
• Once an indicator is made a
target to drive behavior, the
information it holds gets
disqualified.
• KPIs are great servants,
poor masters.

Front 12

Usage Index

Back 12

What % of your product is
used less than 50% of time?
• Build things that people will
actually use.
• If they aren’t, try to figure out
why and drive more usage.
If you can’t, get rid of the
feature.
Higher tends to
be better

Front 13

Securing Success By Securing Scope?

Back 13

Based on the premise that
the initial information and
assumptions are valid
throughout the entire
planning horizon.
• In defiance of this
assumption, the average
software project has a 35%
change in requirements and
around 65% of its
functionality, when
implemented, is never or
rarely used.

Front 14

Take-Away About Value-Driven Development

Back 14

Value in itself is hardly quantifiable.
• Value is an assumption until validated by
the market place.
• Metrics are required to inspect whether
value is effectively delivered.

Front 15

Predictive process - Predictions are impossible

Back 15

Too many variables
• Many unknown variables
• Known variables have unknown
behavior
• The level of details required for
variables is too deep
• Conflicting options emerge while
doing.

A predictive, plan-driven approach is
suited for simple problems.

Front 16

Empirical Process - Predictions are not necessary

Back 16

Inspection and adaptation occurs
as work proceeds
• The right frequency is required
• Transparency is crucial
• Variables can be ignored
• The outcome is continuously
validated against the objectives

An empirical, adaptive approach is
required for complex problems.

Front 17

Definition Of Scrum (n)

Back 17

–framework
• Helping people address complex problems.
• Productively and creatively deliver products of the highest
possible value.

Front 18

The Product Owner In Scrum

Back 18

Manages the Product Backlog
Expresses Product features and functionality
Chooses what and when to release
Represents the stakeholders to the Team

Front 19

Key points for the Product Owner

Back 19

Product Backlog is ordered by the PO, and
refined with the Development Team throughout
the Sprint.
• The team estimates any open PBIs. The PO
clarifies the requirements, but the people
actually doing the work create estimates.
• The Sprint Backlog represents what the Team
thinks it can accomplish during the next Sprint;
contains PBIs and identified work.

• During the Sprint, the Product Owner continues to
refine the Product Backlog.
• Refinement is done by the Scrum Team to help
inform the ordering.
• The Sprint Review is the place where everyone
can see (inspect) what is done.
• The PO accepts what is done, and rejects what
isn’t. Working session, not a “demo.”
• The Retrospective is the opportunity for
inspection of the process, and deciding on
adaptations for the next Sprint.

Front 20

On-Product Index

Back 20

Percent of time a
team spends
working on
product and value

Front 21

Roles, Artifacts & Events

Back 21

Roles
• Product Owner
•Development Team
• Scrum Master
Artifacts
• Product Backlog
• Sprint Backlog
• Increment
Events
• Sprint
• Sprint Planning
•Daily Scrum
• Sprint Review
• Retrospective

Front 22

Abnormal Termination Of Sprints

Back 22

Sprints may be cancelled early
– Only by the Product Owner
– Prefer adjusting Sprint Scope
• Reasons to cancel may include changes in competition,
business, or technology feasibility
• After a Sprint cancellation, conduct a new Sprint Planning
meeting.

Front 23

Sprint Review Reveals Opportunities

Back 23

Removing completed functionality from the Product Backlog.
• Restoring and ordering unfinished functionality to the Product
Backlog.
• Re-ordering the Product Backlog to take advantage of new
opportunities.
• Choosing not to proceed further with the project and not
authorizing another Sprint.
• Requesting that the project progress be sped up by
authorizing additional teams to work on the Product Backlog.

Front 24

Done

Back 24

Have a complete Definition of Done that mirrors “ready to
ship”
• Ensure that the Definition of Done optimizes maintainability,
sustainability and enhanceability
• Adhere to done at least every Sprint
• Adhere more often than every Sprint to avoid surprises at
Sprint end
• Done is for the entire product, not just for a Scrum Team’s
Increment

Front 25

Sprint Retrospective

Back 25

• Scrum Team inspects how the
last Sprint went
– People, relationships, process,
tools
– Definition of Done
• Scrum Team selects actionable
improvements for
implementation in next Sprint

Front 26

Agile Product Manager’s Job

Back 26

Value

•More collaboration (w/team & customer)
•Simplify product absorption
•Leverage entire Scrum Team

Just in time
•Deliver frequently
•Deliver as needed
•Embrace change

ROI
•Optimize productivity
•Deliver only high value items
•Remove negative value items

Front 27

Who Cannot Be Product Owner?

Back 27

• A committee
• A project manager or project leader
• The Scrum Master

Front 28

How Could You Assign Value?

Back 28

• Develop a formula using all appropriate variables.
• Weigh the variables.
• Don’t forget to account for dependencies between variables.
• Apply the formula to each requirement to know the value.

Front 29

Ways to sort requirements

Back 29

Value to existing customers
• Value to prospects
• Value to long term product
viability
• Risk to company and market
• Dependencies
• Commitments
• Complexity
• Effort

Front 30

Product Backlog

Back 30

Inventory of things to be done
• Contains clear acceptance criteria
– Criteria for successful completion
– From Team or Product Owner
• May reference other artifacts like:
– Specifications, Mockups, Architecture Models
• Sized appropriately
– Must be completable within a single Sprint
– Typically with a few other PBIs

Front 31

Characteristics of Product Backlog

Back 31

The single
source of truth
for what is
planned in the
product.

Transparent, i.e. posted and understandable
• Requirements are inventory of
“desirements”
• Ordered based on value, dependencies &
risk
• Work to “do” is estimated
– Prefer relative size, not duration
• A vehicle for starting conversations

Front 32

Valid Product Backlog Items

Back 32

Feature definitions

Constraints

Behaviors

User actions or stories

Bugs/defects

Use Cases

Desirements

Non-functional requirements

Front 33

Emergent Architecture Development

Back 33

Architecture and infrastructure are high ordered non-functional
requirements.
– Or the requirements to fulfill them are included in the definition of
“done.”
• Must be completed to prove that functional requirements can be
implemented satisfactorily
• Every Sprint still must deliver at least some piece of business
functionality
– To prove that architecture or infrastructure works
– To prove to customer that work they care about is taking place
– Basis for estimating

Front 34

Methods Of Backlog Organization

Back 34

Cohesion simplifies development and
implementation

Priority
(either calculated or relative)
Development cohesion
(both product and system)
Business cohesion
(smaller area of business affected)
Implementation cohesion
(a work flow, for instance)
Intentions
(release grouping)

Front 35

Strategic Alignment Index

Back 35

Front 36

Formulate A Release

Back 36

1. Develop a release goal
2. Justify the release to yourself
3. Establish anticipated date and cost
4. Identify major requirements to achieve goal
5. Identify expected capabilities of team
6. Create release product backlog

Front 37

Build Plan As Needed

Back 37

(minimizing unordered inventory)
1. Already funded, underway project – detail inventory for next
several Sprints
2. Unfunded, new project with trust – detail inventory to level
needed to estimate based on history.
3. Unfunded, new project without history – detail inventory to
level where reasonable likelihood of meeting initial plan.
4. Unfunded new project with distrust – detail all inventory and
build trust during project

Front 38

Major release

Back 38

Lots of changes, happen infrequently, freezes other work, relatively stale functionality, high
customer absorption costs.

Front 39

Functional Release

Back 39

Individual pieces of functionality, happen often, most important piece of functionality at the time, relatively low customer absorption costs.

Front 40

Minor Release

Back 40

Lots of broad changes, happen more frequently, often not cohesive, often bug fixes instead of new functionality

Front 41

Customer absorption constraint

Back 41

Customers can’t necessarily use everything you give them.
Focus on what it takes for them to get value from your product.
• Additional Hardware
• Pilots
• Training
• Installation
• Data migration

Front 42

Velocity

Back 42

An option to measure

Velocity is an indication of the ability to turn Product Backlog into shippable functionality across time, or
for a specified price.