CSPO Workbook

CERTIFIED SCRUM PRODUCT OWNER®
MADHAVI LEDALLA
https://lmadhavi.wordpress.com/ Copyright @ 2023-24 Madhavi Ledalla
CSPO Learning Backlog
1. Product Owner Core Competencies
• Fundamentals of the Product Owner Role
• Working with Stakeholders
• Product Ownership with Multiple Teams
2. Describing Purpose and Strategy
• Visioning and Road mapping
3. Understanding Customers and Users
• Discovery and User Research
• Personas
4. Validating Product Assumptions
5. Working with the Product Backlog
• Differentiating Outcome and Output
• Defining Value
• Creating and Refining Items
6. Development Cycle
• Scrum Framework
Copyright @ 2021-24
2023-24 Madhavi Ledalla
PRODUCT DISCOVERY
Product Discovery
• The job of Product discovery is to discover the minimum viable product
that solves the customer’s problem.
• It is a collaboration of the Product Owner , User Experience Design and
Development.
Copyrght @ 2023-24 Madhavi edalla

Product Discovery Introduction
What is Product Discovery? How do you do Product Discovery?

• Process of validating the market
need for your product idea.
• Answers “What we should
build”.
Why Product Discovery? When should you do Product Discovery?

• Should happen before you develop
• Without gathering evidence
your MVP
that a solution has market
• Should continue as the product is
value, companies risk wasting
being built so that it is about both
time building products that
building the right product and
nobody wants or needs.
building the product right
Copyright @ 2023-24 Madhavi Ledalla

Why is Discovery Essential
• A structured way how to come up with solutions that solve the right
problems
• Initial Discovery helps to Identify and Solve the right business
opportunity. It produce value by balancing Business Viability,
Peoples Desirability and Technology Feasibility.
Benefits
• Value driven approach
• Solving the right problems
• Better ways how to frame problems
• Risk of failure gets decreased
• Continuously involves stakeholders
• and as a side effect is innovation

Discovery answers the following
questions-
- Why are we doing this?

- For whom are we doing this?
- What people problem do we solve?
- How are we solving the problem?
- What do we want to achieve?

Discovery & Development

How Do You Do PRODUCT
DISCOVERY

Product Ownership teams
• Focus on doing the discovery work necessary to identify what should be built
• Collaborate with a delivery team to describe exactly what will be built
Ref: https://www.jpattonassociates.com/ Copyright @ 2023-24 Madhavi Ledalla

Discovery Loops
Discovery work focuses on fast learning and validation, the goal is learning, not
working software, a discovery learning loop looks like this-
It starts by describing:
• What we believe is the problem we’re solving and for whom
• The solution we’d build to solve it
• How we’d measure success
Ref: https://www.jpattonassociates.com/ Copyright @ 2023-24 Madhavi Ledalla

FRAMING PRODUCT OPPURTUNITIES
Benifits Of Opportunity Assessment
• Quickly Validate (or Invalidate) Ideas are
– Valuable
– Feasible
– Usable
Before the development team is fully committed
• Helps ensure everyone understands the problem, the context,
and how you will measure success.
• Helps prevent the company from wasting time and money on
poor opportunities, or understand what is required to succeed
for those that are good opportunities.

Assessing Product Opportunities
• Exactly what problem will this solve? (value proposition)

• For whom do we solve that problem? (target market)
• How big is the opportunity? (market size)
• What alternatives are out there? (competitive landscape)
• Why are we best suited to pursue this? (our differentiator)
• Why now? (market window)
• How will we get this product to market? (GTM strategy)
• How will we measure success/make money (metrics/revenue
strategy)
• What factors are critical to success? (solution requirements)
• Given above, what’s the recommendation? (go or no-go)

Opportunity Canvas
Opportunity Canvas allows you to consider the specific user’s problems we’re
solving, and how we think they would use the solution to solve them. And, since it’s
not only about users, you should discuss how users being challenged hurts your
business, and how helping them helps your business.

Understanding Customers and Users
Identify Users (User Research)
User Research is the process of understanding user behaviors, needs, pain points
and motivations through observation techniques, task analysis, and other feedback
methodologies.
Users- people who use your system

• Gather details-
– What will they do with the system, expertise, demographics,
– What benefit do they gain for using your software?
– How do they define success?
– Gather all the information –relevant to how you build your system.
• Summarize all the information into a Persona template
– characteristics of your users, their goals. These directly affect the decisions
made in your product.
• Create a product that meets their goals, works within their knowledge and skill
constraints, and lets them accomplish what they need to.
• Approaches to segment users/customers : customer types, geography,
regulatory bodies
Steps to conduct User Research
1. State Hypothesis – These are our assumptions, what do we think we
understand about our users, in terms of both their behaviors and our potential
solutions to their needs that need validation.
2. Define Objectives -Define the objectives you want to achieve through the
research. The questions we are trying to answer, the knowledge gaps.
3. Select User Research Method -Select a user research method based on the
kind of insight you want to gain. How we plan to fill the gaps in our
knowledge. Based on the time and people available, what methods should we
select?
4. Conduct Research– Carry out the User research and gather data
5. Synthesize the results - Answer our research questions, and prove or disprove
our hypotheses. Analyze the collected data and derive insights from it

User Research Methods

❑ Usability-Lab Studies: participants are brought into a lab, one-on-one with a researcher, and
given a set of scenarios that lead to tasks & usage of specific interest within product / service.
❑ Ethnographic Field Studies: researchers meet with and study participants in their natural
environment, where they would most likely encounter the product or service in question.
❑ Participatory Design: participants are given design elements or creative materials in order to
construct their ideal experience in a concrete way that expresses what matters to them most
and why.
❑ Focus Groups: groups of 3–12 participants are lead through a discussion about a set of
topics, giving verbal and written feedback through discussion and exercises.
❑ Interviews: a researcher meets with participants one-on-one to discuss in depth what the
participant thinks about the topic in question.
❑ Eye tracking: an eye tracking device is configured to precisely measure where participants
look as they perform tasks or interact naturally with websites, applications, physical products,
or environments.
❑ Moderated Remote Usability Studies: usability studies conducted remotely with the use of
tools such as screen-sharing software and remote control capabilities.
❑ Unmoderated Remote Panel Studies: a panel of trained participants who have video
recording and data collection software installed on their own personal devices uses a website
or product while thinking aloud, having their experience recorded for immediate playback
and analysis by the researcher or company.
❑ Diary/Camera Studies: participants are given a mechanism (diary or camera) to
record and describe aspects of their lives that are relevant to a product or service, or
simply core to the target audience; diary studies are typically longitudinal and can
only be done for data that is easily recorded by participants.
❑ Customer Feedback: open-ended and/or close-ended information provided by a self-
selected sample of users, often through a feedback link, button, form, or email.
❑ Card Sorting: a quantitative or qualitative method that asks users to organize items
into groups and assign categories to each group. This method helps create or refine
the information architecture of a site by exposing users’ mental models.
❑ Clickstream Analysis: analyzing the record of screens or pages that users clicks on
and sees, as they use a site or software product; it requires the site to be instrumented
properly or the application to have telemetry data collection enabled.
❑ A/B Testing : a method of scientifically testing different designs on a site by
randomly assigning groups of users to interact with each of the different designs and
measuring the effect of these assignments on user behavior.
❑ True-Intent Studies: a method that asks random site visitors what their goal or
intention is upon entering the site, measures their subsequent behavior, and asks
whether they were successful in achieving their goal upon exiting the site.
❑ Intercept Surveys: a survey that is triggered during the use of a site or application.
❑ Email Surveys: a survey in which participants are recruited from an email message.
Discovery & User Research
• During the early stages of the design process, the key goal is to do
exploratory research. Each project has its own context and specific user
group that research should explore. Questions to ask:
• What do users need?
• What is already working and what isn’t?
• Appropriate methods to be used at this stage include

– 1:1 user interviews,
– focus groups,
– competitive analysis,
– ethnographic research
• User research is often qualitative. It zooms into a small subset of people to

learn about who they are and what they want. As a result, product teams can
create products specifically for their user. User Researchers run usability
tests, 1-1 qualitative surveys, focus groups, and ethnographic studies. They
intend to understand what someone thinks about an existing product and
where it can be improved.
Creating Personas
Personas are a powerful technique to describe the users of a product in
order to make the right product decisions. Personas are
fictional characters, which you create based upon your research in order
to represent the different user types that might use your service or
product. Creating personas helps the designer to understand users' needs,
experiences, behaviors and goals.
Usability.gov recommends the following steps for creating personas:
1. Conduct User Research
- Focus groups, surveys, etc.
2. Condense the research
- Look for high level themes
3. Brainstorm
- Organize elements into persona groupings
4. Refine
- Combine and prioritize rough personas
- 3-5 personas is considered ideal
5. Make them realistic
Empathy Map
-An empathy map is a collaborative tool teams can use to gain a deeper
insight into their users. It is a collaborative visualization used to
articulate what we know about a particular type of user. Originally
created by Dave Gray
-Gather the research you will be using to fuel your empathy map.
Empathy mapping is a qualitative method, so you will need qualitative
inputs: user interviews, field studies, diary studies, listening sessions,
or qualitative surveys.

Pain Gain Map
The Value Proposition Canvas is a tool which can help ensure that a product or
service is positioned around what the customer values and needs. The Value
Proposition Canvas was initially developed by Dr Alexander Osterwalder as a
framework to ensure that there is a fit between the product and market

Identify Customers (Market Research)
• Customers are people who buy the product. Customer profiles describe
the factors customers use to make decisions , what influences them and
what they value.
• Don’t mix them up with your users – even if they’re the same people
• Market researchers study consumer behavior and identify their
needs. They uncover demographic, economic, and statistical information
about a specific industry.
• Market research delivers business insights on market needs, size,
competition and pricing. They use quantitative methods, meaning they
focus on numbers. They look at large sample sets to understand the
average age of potential users, their income level, and other general
characteristic
Both Market Researchers and User Researchers use data to inform better
decisions. When applied correctly, they minimize business risks, and provide
a clear roadmap for stakeholders to create successful products. Overall,
companies are encouraged to follow both practices to achieve success.

Market research
• Market segmentation is the process of dividing
• What is the market size? a target market into smaller, more defined
• What is the market categories. It segments customers into groups
forecast? that share similar characteristics such as
• Which countries drive the demographics, interests, needs, or location
most demand? • If you’re building a commercial product, and
• What are opportunities? don’t segment your market, you run the risk of
• What are challenges? satisfying no one
• What are price points?
• Who are the main
competitors?
• What type of revenue do
these products bring in?
• How fast are is the
industry growing?

IDENTIFY POSSIBLE SOLUTIONS

6-8-5 Sketching
6–8–5 Sketching is a brainstorming method that helps designers produce atleast 6 to 8
ideas within 5 minutes.
This is usually be performed early in the Ideation phase. Due to the tight time
constraints, it forces designers to come up with the “best” idea and leave behind their
focus on detailed solutions.
The goal is to get creative and come up with as many ideas that solve for a problem as
quickly as possible.

Storyboarding
Storyboards are great to explore and describe how a user interacts with a product. Take the ideas
you’ve generated so far, and sketch how a user would move through part of a user story.
Storyboards illustrate the interaction required to achieve a goal. But instead of using a list of
steps, a storyboard visualizes the interaction similar to a comic strip.

Connecting Development Team to customers/users
• Sprint Review
• Job shadowing
• Customer interviews
• Customer observation
• Collaborative customer games
• Usability testing
• Simulating customer experience.
• Benefits
– empathizing with customer needs, mutual
understanding, shorter feedback cycles

VALIDATE WITH USERS

Validating Assumptions
The purpose of idea validation is to make sure your product or business
idea has potential and the most critical assumptions regarding your
idea are valid. The point is to find the fastest and cheapest way to test
your assumptions so that you can decide whether you're going to
proceed with the idea or pivot.
• Contextual Inquiry Interviews

Criteria for prioritizing the
• Ethnographic research
assumptions for validations
• Direct user observation
• highest business risk
• A/B testing
• most opportunity for learning
• Prototypes
• highest technical risk,
• Focused groups
• Heat maps
Scrum framework supports this validation using each Sprint to

experiment and learn about the product, specific process
adaptations, and the followed plan.

Methods
• Function Prototypes: Allows the design team to explore ideas before implementing them by creating a
mock-up of the site.
• Paper Prototypes : Test our proposed product or services value proposition and usability in low fidelity.
• Contextual Inquiry Interviews - Observe users interacting with your product or prototype, asking
probing questions into the how and why of their actions
• Heatmaps: This method allows eye and gesture-tracking to figure out which parts of your website or app
drive the most engagement
• Focus Groups: Moderated discussion with a group of users, allow you to learn about user attitudes,
ideas, and desires
• Behaviour Tests: Understand actual customer behavior when they are interacting with our product or
service.
• Customer Games: Use visual thinking metaphors and group interaction to uncover latent needs or
converge multiple possibilities to concrete decisions.

Contextual Inquiry Interviews
Contextual inquiry is a semi-structured interview method to obtain information about the
context of use, where users are first asked a set of standard questions and then observed
and questioned while they work in their own environments. Observe users interacting
with your product or prototype, asking probing questions into the how and why of their
actions. As its name describes exactly what makes it valuable — inquiry in context
• Context: The research takes place in the users’ natural environment as they conduct their
activities the way they normally would. The context could be in their home, office, or
somewhere else entirely.
• Inquiry: The researcher watches the user as she performs her task and asks for information to
understand how and why users do what they do.
.

Card Sorting
Let your potential users group and organize the building blocks of your product to
validate navigation and taxonomy. The card sorting method is used to generate
information about the associations and grouping of specific data items.
Participants in a card sort are asked to organize individual, unsorted items into
groups and may also provide labels for these groups. They group individual labels
written on notecards according to criteria that make sense to them. This method
uncovers how the target audience’s domain knowledge is structured, and it serves
to create an information architecture that matches users’ expectations.

A/B Testing
A/B testing - a technique of showing two or more variants of a design to users at random to
find out which one performs better - is just one approach you can use. Test different solutions
against each other in your product’s environment to see which performs the best.
It is a research that allows you to evaluate two variants of a webpage, for example, and find
out which of them is more effective. It forces you to stop making design decisions based on
your personal preferences, biases, and ego, and instead lets your users ‘vote’ via their behavior

PRODUCT STRATEGY
Product Strategy
• Vision as the ultimate reason for creating the product
• Strategy as a path to the vision, then the vision guides the strategy
• Ex- create a health app that helps people become aware of what and how much
they eat. The vision could be to help people eat healthily, and the strategy might
be to create an app that monitors the food intake.
Ref: https://www.romanpichler.com/
Product Box
• Product Box is a collaboration framework that lets you
leverage your customer’s collective retail consumer
experiences by asking them to design a product box for your
product. Not just any box, but a box that represents the product
that they want to buy.
• Design includes
– Title /Name
– Catchy graphics
– 3-4 key features

Elevator Pitch
An elevator pitch or elevator speech is basically a short sales pitch. The name is
derived from the concept of being able to sell your small business’ service or products
within the time frame in which you’d share an elevator ride with somebody. This means
being able to communicate the most important parts of your enterprise succinctly and
clearly.
For <description of the users>

Who <description of what the users need>
The <name of product/service>
Is a <description of type of product/service>
That <compelling benefit>
Unlike <description of the competitive alternative>
Our product <primary differentiator>

Vision Board
Defining the product strategy with the Product Vision Board

DEVELOPMENT CYCLE

Delivery Loops
• At the end of every test (discovery loop) you’ve got a decision
to make: build it, kill it, or keep learning.
• Both development and discovery work are critical. But the
mindset you approach the work with, and your process for doing
it, are very different.

• What organizational
Product Thinking goals does building this
Product Thinking needs to move the software help realize?
focus from fast output to outcome and
How will your company benefit
impact! after the product has shipped? If
you understand how, do others?
Attributes to think that help in

maximizing the outcome-
- who needs it,
- why do they need it,
- how to test it,
- why it is valuable,
- how long it might take to
build.
Output is the software built, the stuff you ship.
Outcome is what you get after the software ships
Product Backlog
PRIORITY SIZE CLARITY
• The Product Backlog is an ordered list
Certain
of product backlog items (PBIs) i.e the
Small
High
requirements
• Attributes of PBI
• who needs it,
• why do they need it,
• how to test it,
• why it is valuable,
• how long it might take to build.
Uncertain
Big
Low
Mike Cohn’s DEEP acronym

specifies the attributes of a healthy
backlog
Obsolete or
Not needed any more

Product Backlog Items
Each Product backlog item has a ID, Description, Order, Value, Estimate and
the Sprint to which it belongs to and the Acceptance criteria.
P
R
New features
O
D
U Defects
C
T
Knowledge
PRODUCT BACKLOG Acquisition
ITEMS
B
A Technical Debt
C
K Research
L Items
O
..
G
All the work done by the development team is made visible in the Product Backlog.
“If it’s not on the Product Backlog, then it doesn’t exist”.

Product Backlog Refinement
Sprint
Daily Scrum
Planni
ng
Sprint Review
Sprint Planning Sprint
Sprint Sprint Sprint
Retrospective
Plannin Planning
g
Sprint Backlog
Product Backlog Increment
Refinement is an on-going process
Product Backlog refinement is the act of breaking down and further defining the Product
Backlog items into smaller more precise items. It is an ongoing activity during which the
Product Owner and the Developers collaborate on the details of Product Backlog items.
Approaches Benefits
– User story brainstorming - Helps Scrum Team to focus on priority items
– Customer interviews - Brings transparency on upcoming sprints work
– Open planning meeting - Helps developers plan their Sprints better as they gain clarity
– Collaborative games.
Criteria for Ordering
- strategic alignment
- business value
- user value
- learning value
- time to market
- estimated cost of building
- risk

Product Backlog management

Planning Levels
52

Product Roadmap
A product roadmap communicates how a product is likely to evolve, it is used to
communicate a high level plan to both development teams and stakeholders

GO-ROADMAP
The GO product roadmap is a new, goal-oriented product planning tool developed to
fit into a Lean Startup, Business Model Generation and Scrum context. By focusing
on goals, the roadmap shifts the conversation from debating features to establishing
shared objectives
http://www.romanpichler.com/blog/working-go-product-roadmap/

GO Portfolio Roadmap
The GO Portfolio Roadmap combines the roadmaps of
several related products into a single plan. The portfolio
roadmap is based on goals; you create it by identifying the
desired benefits the portfolio members should deliver.

Release Planning
The purpose of Release Planning
is to establish a baseline of the
Product Backlog Items or
feature/functions that will
comprise the next
implementation.
A release plan forecasts how a
major release is developed. It’s a
type of project plan—albeit an
agile one—and it usually covers
the next three to six months

Release Planning
Inputs: Release strategy, Prioritized product backlog
Create a Release plan with high level estimates
All involved Scrum teams, stakeholders, management, who ever is needed.
1- 2 days, depends on the number of teams and duration of release
Beginning of the release, however it is continuously revisited as more is learnt

and updated based on team velocity.
Output: Release plan, scope, risks and dependencies identified, Release backlog,
individual team draft plans, supporting visual radiators like release burnup chart etc.

57
Release Strategy
The product roadmap is a holistic view of the product's requirements and a valuable
tool for planning and organizing the product development process.
ROADMAP
Release 1 Release 2 Release 3
S1 S2 S3 S1 S2 S3 S1 S2 S3
or
Scope is fixed Time is fixed
Release Forecast (fixed scope)

Size of backlog (100 points) Team Velocity (10 pts/sprint) Duration = Size / velocity (10 sprints)
Release Forecast (fixed time)

Scope that can be delivered = 100 58
Time Available: 10 sprints Team Velocity (10 pts/sprint) features (10 *10: velocity * sprints)

USER STORIES
PRODUCT BACKLOG CREATION
• Use Cases
• Scenarios
• Process Flows
• Mock-Ups / Wireframes
• Given-When-Then
• Data Flow Diagrams
• ATDD
• Story Mapping
• More….

User Stories
According to Ron Jeffries, User Story is just a token for conversation.
A story is made up of 3Cs
• Card: The requirement is specified very briefly.

The card is a token representing the requirement.
• Conversation : The requirement is communicated and clarified between the team
and customers while conversations, these conversations are for having a shared
understanding of what to build. The shared understanding is captured in the form
of acceptance criteria.
• Conformation: Come up with a set of conformation tests to verify the
functionality discussed during the conversation is actually built.
A user story is a short, simple description of a feature told from the perspective of the
person who desires the new capability, usually a User or Customer of the system” –
MikeCohn
User stories are typically written in the following format:

As a <Type of User> I want <goal> So that <purpose>
This talks about WHO (User) , WHAT (functionality) and WHY(Value) 61

Acceptance Criteria
As a book shopper, I want to order and pay for the book via a secure
web-based form, so that my credit card information is safe.
Acceptance Criteria:
• All mandatory fields must be completed before a customer can submit a
form.
a. Name, b. Email address, c. Phone Number d. License Number
(Power/Basic/None)
• Payment can be made via Amex, Master Card, or Visa credit card.
• The system shall accurately calculate and apply sales tax.
• The system shall accurately calculate and apply shipping charges.
• An acknowledgment email is sent to the shopper submitting the form.

Acceptance Criteria
Recommended format:
<Given-When-Then>
▪ The given part describes the Context, You can think of it as the pre-conditions to
the test.
▪ The when section describes the Event, the behaviour that you're specifying.
▪ The then section describes the Outcome changes you expect due to the specified
behaviour
Scenario - Account is in credit, withdraw cash from ATM
Feature: Secure login for e-payment
Scenario: New User

Acceptance Criteria:
Given I am a non-registered user
When I make payment online for movie tickets
Then it should say “Please create account before making payment”, and
redirect to registration page
Epic and Theme
EPIC is a big user story yet to be split, It is a compound user story that is worth to
be split into smaller stories consumable during the sprints.
THEME is a collection of related user stories , set of related stories used for
grouping. Can be used while release planning. Ex: User Management, Security,
Reporting.. Search by author
As a customer I want Search by title

search a eBook
Search by language
As a customer I want buy As a customer I want add
a eBook so that I can read books to my shopping
online. cart
Pay by American
express
As a customer I want to
Pay by Visa Card
make payment online
Pay by PayPal acc

64

Story Splitting techniques

Prioritization Techniques
Prioritization prerequisites
• Before we can prioritize user stories about software to build, we

must first prioritize our business goals, our customer groups, or
potential users, our users goals, and the kinds of uses they have
• Business and product goals, customers, users form the basis of
backlog prioritization.
• Prioritizing a backlog without a commonly understood basis for
prioritization is contentious.
• Depending on your industry there may be regulatory concerns
that come into play, architectural concerns etc..

Defining Business Value
• Begin with a vision, then conduct experiments to understand what
your customers really want
• Gain and incorporate customer feedback and then gather more
feedback
• By delivering what customers want and will use, you create and
delivery true business value
• Examples of value:
- actual value to customer,
- return on investment,
- maximizing learning,
- risk/de-risk,
- acquiring new customers.

Criteria for backlog prioritization
• Know who are the users of the product

• How they intend to use the product
• Are the users part of our target market segment or not
• The amount and significance of learning and new
knowledge created by developing new features
• The amount of risk removed by developing the features
• The financial value of having the features
• The cost of developing/supporting the new features
• How is the feature aligned to strategic outcomes

Measuring Value
• Usage metrics
• NPS
• Customer and user interviews
• Direct observation
• ROI
• Profitability of the product
• Customer feedback

Prioritization Methods
How does your organization prioritize?
• Financial Criteria (NPV, IRR, ROI)

• MoSCoW
– Must have
– Could have
– Should have
– Won’t have
• Kano Analysis
• Buy a Feature

Prioritizing: KANO Analysis
Kano Prioritization
• Four classification system

– Must Be – baseline features
– Satisfiers – the more the better
– Delighters – at least one or two
– Dis-satisfiers – don’t deliver these
• A categorization approach is not true prioritization

– Release Planning will need more granularity and detail

MoSCoW Method
• MUST - critical to project success and. If one MUST is not included,

the project delivery is a Failure.
• SHOULD - important to project success, but not necessary for the current
delivery time box. SHOULD requirements are as important as MUST, yet are
often not as time-critical or have workarounds and so can be held back until a
future time box.
• COULD - are less critical and often are nice to have. A few easily
satisfied COULD requirements in a delivery increases customer satisfaction.
• WON'T - requirements are not planned into the schedule for the
delivery. WON'T requirements are either dropped or reconsidered for inclusion in
later time boxes. This, however doesn't make them any less important.
Buy a Feature
Create a list of features with an estimated

cost. The cost can be development effort
or actual cost you intend to charge for the
feature. Customers buy features that they
want.
Features are priced high enough that no

singe customer can buy the features. This
helps motivate customers to negotiate
between themselves as to which features
are most important. Observation of this
Goal: negotiation provides great insight into
Prioritize features. what customers are willing to pay for.

THE SCRUM FRAMEWORK
Copyright @ 2023-24 Madhavi

75 Ledalla
AGILE VALUES

AGILE PRINCIPLES

SCRUM FRAMEWORK
Scrum is founded on empiricism and lean thinking,
employs an iterative, incremental approach to optimize
predictability and to control risk. Scrum combines four
formal events for inspection and adaptation within a
containing event, the Sprint.
Risks of partial implementation of

Scrum:
- Reduces transparency
- Seize the opportunity for the
team to inspect and adapt

PILLARS OF EMPERICAL PROCESS
Scrum is founded on empiricism and lean thinking. Empiricism
asserts that knowledge comes from experience and making
decisions based on what is observed. Lean thinking reduces waste
and focuses on the essentials.
Transparency Inspection Adaption

If any aspects of a process
The emergent process and Scrum artifacts and the
deviate outside acceptable
work must be visible to progress toward agreed goals
limits or if the resulting
those performing the work must be inspected frequently
product is unacceptable, the
as well as those receiving and diligently to detect
process being applied or the
the work potentially undesirable
materials being produced
variances or problems 79
must be adjusted
SCRUM TEAM
The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. It is
Cross-functional and Self-managing, thus they can work independently and tend to be creative
and productive at solving problems
The Product Owner is The Scrum Master is Developers are the people
accountable for accountable for in the Scrum Team that
maximizing the value of establishing Scrum as are committed to creating
the product resulting from defined in the Scrum any aspect of a usable
the work of the Scrum Guide. Increment each Sprint.
Team

Scrum Values
OPENNESS COURAGE
FOCUS
RESPECT COMMITMENT
The Scrum Team commits to achieving its goals and to supporting each
other. Their primary focus is on the work of the Sprint to make the best
possible progress toward these goals. The Scrum Team & its stakeholders
are open about the work & the challenges. Scrum Team members respect
each other to be capable, independent people, and are respected as such by
the people with whom they work. The Scrum Team members have the
courage to do the right thing, to work on tough problems. 81

Scrum Master :right team/process
Coaching the team Helping the Scrum

members in self- Team focus on Facilitate Scrum
management and creating high-value events to be positive
cross-functionality Increments and productive
82

DEVELOPERS
Self-managing &
Cross-functionalelf-
directing &
Self-managing
Accountable for
• Creating a plan for the Sprint, the Sprint Backlog
• Instilling quality by adhering to a Definition of Done
• Adapting their plan each day towards the Sprint Goal and
• Holding each other accountable as professionals

PRODUCT OWNER

Scrum Artifacts
Scrum’s artifacts represent work or value to provide transparency and
opportunities for inspection and adaptation .
Key Artifacts
1. Product Backlog
2. Sprint Backlog
3. Increment Sprint
Daily Scrum
Plannin
g
Sprint Review
Sprint Planning Sprint
Sprint Sprint
Retrospective
Plannin Planning
g
Sprint Backlog Releasable/Usable

Items selected for the sprint Increment
Product Backlog
Wish list of customers Done Items
85

Artifacts & Commitments
Product Backlog: Sprint Backlog: Increment:

Is ordered list of what Composed of Sprint Goal Each Increment is additive to
is needed to improve (why), the set of Product all prior Increments and
the product Backlog items selected for the thoroughly verified, ensuring
Sprint (what), as well as an that all Increments work
actionable plan for delivering together
the Increment (how).
Commitment: Sprint Goal Commitment: Definition of
Commitment: Product Goal
It is the single objective for the Done
Describes a future state of the
Sprint. It provides flexibility in It is a formal description of
product which can serve as a
terms of the exact work needed the state of the Increment
target for the Scrum Team to
to achieve it. when it meets the quality
plan against.
measures required for the
product.
Definition of Done
To-Do Doing Done

FLOW
▪ The Definition of Done is a shared understanding, a common definition of what it means

to be done.
▪ It is the checklist types of work that the team is expected to successfully complete before
it can declare an item to be potentially shippable.
▪ It evolves, as the Team gets closer and closer to being able to produce an integrated tested
Product Increment in every Sprint.
87

Definition of Done and Acceptance Criteria
DOD Acceptance Criteria
▪ List of criteria that needs to be met in ▪ List of criteria that needs to be built in,
order for a requirement to be marked in order to develop the required
as done from all aspects( Quality) functionality (Scope)
▪ Completeness criteria of a Product ▪ Acceptance criteria to accept/reject
backlog item. Product backlog item.
▪ Helps us build the thing right ▪ Helps us build the right thing
(How – Quality ) (What - functionality)
▪ Applies to all backlog items ▪ Unique to each backlog item
88

SCRUM EVENTS
Beginning
SPRINT End
Analysis Analysis Analysis Analysis Analysis Analysis
RETROSPECTIVE
Coding Coding Coding Coding Coding Coding
PLANNING
REVIEW
Test Test Test Test Test Test
.. .. .. .. .. ..
.. .. .. .. .. ..
.. .. .. .. .. ..
DAILY DAILY DAILY DAILY DAILY DAILY
SCRUM SCRUM SCRUM SCRUM SCRUM SCRUM
One month or less
- Sprints are fixed length events of one month or less, the timeboxes help to create
consistency, forces prioritization and improves predictability.
- The Sprint is a container for all other events. Sprints enable predictability by
ensuring inspection and adaptation of progress toward a Product Goal at least every
calendar month.

SCRUM EVENST Cont..
EVENT DURATION PURPOSE

Sprint Planning 8 hors max for 1 month Plan the work to be performed for the
Sprint Sprint
Daily Scrum 15 minutes Inspect progress toward the Sprint
Goal and adapt the Sprint Backlog as
necessary
Sprint Review 4 hours max for one Inspect the outcome of the Sprint and
month Sprint determine future adaptation
Sprint 3 hours max for one Inspect the sprint and plan ways to
Retrospective month Sprint increase quality and effectiveness.
During the Sprint

● No changes are made that would endanger the Sprint Goal
● Quality does not decrease
● The Product Backlog is refined as needed and
● Scope may be clarified and renegotiated with the Product Owner as more is learned.

PRODUCT OWNER
Organizational Contexts:
Development team
• Product Owner has
Vision & Strategy complete ownership of
target customer, problem,
and solution
Stakeholders
& competitors • Product Owner owns the
delivery of someone else’s
idea or initiative
Other Business
• Product Owner delivers a
Groups Product Owner shared service to other
teams in the organization
B
A
• Product Owner works on
C short-term projects for
Sales
K which they own the
L outcome
O
Marketing
G 91

Common Product Owner Mistakes
http://www.romanpichler.com/ Copyright @ 2023-24 Madhavi Ledalla

Product Ownership with
Multiple Teams

Classic view of Product Owner
Single person
Solely responsible for:
– Requirements gathering
– Answering team’s questions
– Setting priorities for product, release, and sprint
• Gatekeeper for what gets worked on
– All “non-IT” related project management
• Org Readiness

Problems with Classic View
Rare that a single person has the correct

combination of knowledge, authority and
available time to fulfill the role
– Inverse likelihood as the size of an
organization grows
Not a scalable solution

– Most Scrum theorists refer to “chief product
owner” when there are multiple teams

Tips to overcome challenge of being a
PO for multiple teams
• Delegating some of the work to the team

members
• Redefine product backlog items to reduce
dependencies
• Having some form of Scrum of Scrums to
resolve and reduce dependencies

LeSS

SAFe

WORKING WITH STAKEHOLDERS

Stakeholder Engagement
• Stakeholders- Those who have the interest and influence to impact
your product, program, team, or project.
• Understand how to identify and classify types of stakeholders
• Identify a framework for continuous stakeholder engagement
End Users are Stakeholders, Stakeholders may not be End

Users

Stakeholders Types
• People who
– Impact your project
– Enhance your project (SMEs)
– Dependent teams
– Support the projects
• External influences
– Subcontractors End Users are Stakeholders
– Suppliers
– Competitors Stakeholders may not be End Users
– Regulatory agencies
• Others
– IT Ops
– Production support

Stakeholder Responsibilities
• Remain engaged from the definition to the completion of the feature

• Provide ongoing feedback and support
• Define and clarify requirements
• Collaborate with the Product Owner
• Contribute to the growth of a trusting Agile environment

Analyzing Stakeholders
Mapping stakeholders in two dimensions
Power /Influence interest matrix
Considerations for prioritizing

stakeholders:
- Influence (not just power)
- Interest/availability
- Attitude
- Time criticality

Engaging Stakeholders
• Requirements Workshops
• Brainstorming sessions
• Interviews
• Questionnaires
• Information Gathering
– Affinity Grouping
– Dot Voting
– Fist of five
– Collaboration games(Buy a Feature)

Providing transparency to stakeholders
Determine your touch points
– One-on-one conversations
– Develop a Cadence
– Invite them to Sprint reviews
– Review Roadmap and Release Plan regularly
– Review expectations for delivery
– Escalate impediments
– Given early access to products to learn first hand what they really need and/or
want
– Using visual radiators like release burn-up charts.
Stakeholder management plan

Release Burnup Chart
▪ The Release Burn-up chart displays the value accumulated so far, i.e shows the amount of
work completed so far
▪ Used to monitor health of the current release
▪ Spans across the iterations in the release
▪ Product owner updates the release burn-up chart after every sprint
▪ The work completed is tracked on y-axis and the iterations on the x-axis
106

Release Burndown chart
▪The Release Burn-down Chart is used to track the amount of work left in a release
▪Used to monitor the health of the release.
▪Spans across the iterations of the release.
▪The remaining work is tracked on y-axis and the time period on the x-axis.
▪It can be extrapolated to forecast whether the release will get completed as planned,.
107

Closing and RETROSPECTIVE!
▪ What did you learn today?

▪ Make your learning log?
▪ Write down what are the three things that you are going
to change and start working on right away from
tomorrow
▪ Discuss with the person next to you.
108

NOTES

Notes

References
• https://www.romanpichler.com/
• https://www.jpattonassociates.com/
• https://lean-startup-coaching.com/comment-utiliser-un-lean-canvas
• https://www.nngroup.com/articles/which-ux-research-methods/
• https://www.designabetterbusiness.tools/tools/persona-canvas
• https://www.romanpichler.com/blog/agile-scenarios-and-storyboards/
• https://www.yieldify.com/blog/types-of-market-segmentation/
• https://www.usabilitybok.org/
BOOKS
• User Stories Applied: For Agile Software Development by Mike Cohn

• Agile Estimating and Planning by Mike Cohn
• How to Lead Product Management by Roman Pitchler

CSPO Workbook

Uploaded by

Copyright:

Available Formats

You might also like

CSPO Workbook

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CSPO Workbook

Uploaded by

Copyright:

Available Formats

CERTIFIED SCRUM PRODUCT OWNER®

Copyrght @ 2023-24 Madhavi edalla

What is Product Discovery? How do you do Product Discovery?

Why Product Discovery? When should you do Product Discovery?

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

- Why are we doing this?

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Ref: https://www.jpattonassociates.com/ Copyright @ 2023-24 Madhavi Ledalla

Ref: https://www.jpattonassociates.com/ Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

• Exactly what problem will this solve? (value proposition)

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Users- people who use your system

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

• Appropriate methods to be used at this stage include

• User research is often qualitative. It zooms into a small subset of people to

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

• Contextual Inquiry Interviews

Scrum framework supports this validation using each Sprint to

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

For <description of the users>

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Attributes to think that help in

Mike Cohn’s DEEP acronym

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Refinement is an on-going process

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Copyright @ 2023-24 Madhavi Ledalla

Create a Release plan with high level estimates

All involved Scrum teams, stakeholders, management, who ever is needed.

1- 2 days, depends on the number of teams and duration of release

Beginning of the release, however it is continuously revisited as more is learnt