Product Owner in Agile/Scrum is the single person responsible for maximizing the return on investment (ROI) of the development effort
Responsible for product vision
Constantly re-prioritizes the Product Backlog, adjusting any long-term expectations such as release plans
Final arbiter of requirements questions
Decides whether to release
Decides whether to continue the development
Considers stakeholder interests
May contribute as a team member
Has a leadership role
Must be available to the Team at any time
2. Agenda
Introduction
Agile Manifesto
Agile Principles
Scrum Framework
User Stories
DoR, DoD
Estimation Techniques
Technical Debt
Product Vision
Product Value
Agile Metrics
Business Strategy
Design Thinking
Product Backlog Management
Release Planning & Management
Self-Managing Teams
Value-Driven Development
3. PSPO Certification Details
Passing score: 85%
Time limit: 60 minutes
Number of Questions: 80
Format: Multiple Choice, Multiple Answer, True/False
$200 USD per attempt
Passwords have no expiration date, but are valid for one attempt only
Lifetime certification - no annual renewal fee required
4. Problems Companies Faced
Time-to-market for products is too long
Project failure rate is unacceptably high
ROI delivered frequently falls short
Responding to change is difficult and costly
Customer orientation is weak
Software quality is poor
Productivity could be higher
Employee morale, drive and accountability is low
Widespread micromanagement is required
And so so ……
5. Why Agile ?
Agile works on fail fast philosophy
Team empowerment to take decisions
Real-time communication,
A high degree of flexibility
Minimize risk by short iterations
Customer satisfaction
Flexibility to incorporate new requirements or modify
existing requirements
Promote Supportive Culture
Promotes the sharing of knowledge
Promises a high probability of success
6. What is Agile?
Agile is a software development methodology in which
the development is carried out iteratively and the
requirements evolve through continuous inspection and
adaptation.
Some of the most commonly used agile software
development frameworks are -
Scrum
Kanban
Lean
Adaptive Software Development (ASD)
Extreme Programming (XP)
Test - Driven Development (TDD)
Dynamic System Development Methodology (DSDM)
7. Manifesto for Agile Software Development
Individuals and interactions over processes
and tools
Working software over comprehensive
documentation
Customer collaboration over contract
negotiation
Responding to change over following a plan
8. Principles of Agile Manifesto
Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for the
customer's competitive advantage.
Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to the
shorter timescale.
Business people and developers must work together
daily throughout the project.
Conti…
9. Principles of Agile Manifesto
Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the
job done.
The most efficient and effective method of conveying
information to and within a development team is face-to-face
conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Conti…
10. Principles of Agile Manifesto
Continuous attention to technical excellence
and good design enhances agility.
Simplicity-the art of maximizing the amount
of work not done-is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts its
behavior accordingly.
12. Agile –“Doing what come naturally”
Aligned with how we actually make software
Think about the project for a bit
Write code
Adjust as needed
13. Scrum
Definition from rugby football: Scrum is a way to restart the
game after an interruption, where the forwards of each side come
together in a tight formation and struggle to gain possession of
the ball when it is tossed in among them.
14. Why Scrum?
Faster - Scrum helps teams continuously improve, so that
they can produce more in less time.
Better - Scrum puts the customer at the center of design and
development, resulting in more commercially successful
products.
Happier - Scrum empowers working teams to make decisions
and harness their talents, leading to greater employee
satisfaction.
15. History of Scrum
Ken Schwaber and Jeff Sutherland developed the Scrum
method in the early 1990’s. The Scrum method has evolved
somewhat over the years.
The definitive guide to the rules of Scrum, The Scrum Guide,
is maintained by Ken Schwaber and Jeff Sutherland. [The
most recent edition of The Scrum Guide was published in
2016.]
17. Scrum Overview
Scrum
Scrum is a management framework for incremental product
development using one or more cross-functional, self-
organizing teams of about seven people each.
It provides a structure of roles, meetings, rules, and
artifacts. Teams are responsible for creating and adapting
their processes within this framework.
Scrum uses fixed-length iterations, called Sprints, which are
typically two weeks or 30 days long. Scrum teams attempt
to build a potentially shippable (properly tested) product
increment every iteration.
20. Sprint
The heart of Scrum is Sprint, a time-box of one
month or less during which a "Done" useable and
potentially releasable product increment is created.
Sprint is the basic unit of Scrum development and is
restricted to a specific duration Product backlog.
Each sprint may be considered a project with no
more than a month or four week duration.
Each Sprint has a definition of what is to be built, a
flexible plan, that will guide building it, the work,
and the resultant product.
25. Product Backlog
Force-ranked list of desired functionality
Visible to all stakeholders
Constantly re-prioritized by the Product Owner
Items at top are more granular than items at bottom
Maintained during the Backlog Refinement Meeting
26. Product Backlog
Specifies the what more than the how of a customer-centric feature
Often written in User Story form
Has a product-wide definition of done to prevent technical debt
May have item-specific acceptance criteria
Effort is estimated by the team, ideally in relative units (e.g., story
points
Different Backlog Items are defined at different levels of specificity
Most important items at the top, defined in greater detail
Items further down the backlog don’t need as much detail
27. Sprint Backlog
Consists of selected PBIs negotiated between the
team and the Product Owner during the Sprint
Planning Meeting.
No changes are made during the Sprint that would
endanger the Sprint Goal.
Initial tasks are identified by the team during Sprint
Planning Meeting.
Team will discover additional tasks needed to meet
the Sprint Goal during Sprint execution.
Visible to the team.
Referenced during the Daily Scrum Meeting.
29. Product Owner
A single person representing the
stakeholder(s) and/or customer(s)
Has final authority in creating and
ordering the product backlog
30. Roles of Product Owner
Single person responsible for maximizing the return on
investment (ROI) of the development effort
Responsible for product vision
Constantly re-prioritizes the Product Backlog, adjusting
any long-term expectations such as release plans
Final arbiter of requirements questions
Decides whether to release
Decides whether to continue development
Considers stakeholder interests
May contribute as a team member
Has a leadership role
Must be available to the Team at any time
31. Product Owner
Skills
• Negotiation
• Decision-making
• Communication
• Persuasion
• Multi-level thinking
Characteristics
• Passion for the customer
/user
• Influencing rather than
controlling
• Knowledgeable
• Patient
Challenges
• Multiple constituencies
• Limited capacity
• Other roles/responsibilities
• Lack of trust/confidence
Who typically plays this
role?
• Product Manager
• SME
• Manager
• BA
• And lots of others…
32. Scrum Master
Facilitates the Scrum process and
Team self-organization
Helps the Product Owner to understand,
create and manage the PBIs
A Scrum Master is a servant-leader whose focus is on the needs
of the team members and those they serve (the customer), with
the goal of achieving results in line with the organization’s values,
principles, and business objectives.
33. The Servant Leader
The servant-leader’s objective is to enhance and increase
teamwork and personal involvement. They create a participative
environment, empowering ‘employees’ by sharing power and
decision-making.
A servant-leader:
Focuses on building a foundation of trust
Stimulates empowerment and transparency
Encourages collaborative engagements
Is an un-blocker and empathetic person able to truly listen
Shows ethical and caring behaviour, putting others’ needs first
Is humble, knowledgeable, positive, social and situationally
aware
34. Scrum Master to Product Owner
Finding techniques for effective Product Backlog
management
Helping the Scrum Team understand the need for clear
and concise Product Backlog items
Understanding product planning in an empirical
environment
Ensuring the Product Owner knows how to arrange the
Product Backlog to maximize value
Understanding and practicing agility
Facilitating Scrum events as requested or needed
35. Scrum Master to The Team
Coaching the Development Team in self-organization and
cross-functionality
Helping the Development Team to create high-value
products
Removing impediments to the Development Team’s
progress
Facilitating Scrum events as requested or needed
Coaching the Development Team in organizational
environments in which Scrum is not yet fully adopted and
understood
36. Scrum Master to The Organization
Leading and coaching the organization in its Scrum
adoption
Planning Scrum implementations within the organization
Helping employees and stakeholders understand and
enact Scrum and empirical product development
Causing change that increases the productivity of the
Scrum Team
Working with other Scrum Masters to increase the
effectiveness of the application of Scrum in the
organization
37. Scrum Master
Skills
• Coaching/Mentoring
• Agile project planning
• Facilitation
• Conflict Management &
Resolution
• Scaling Agile
Characteristics
• Responsible
• Collaborative
• Influential
• Perceptive
• Experienced
Challenges
• Lack of support
• Limited availability
• Scrum is new to the team
• Team actively resists new
process
• Working in a non-agile
environment
Who typically plays this
role?
• Project Manager
• Project/ Technical Lead
• Team Lead
• Development Team Member
• Manager
40. Roles of Development Team
Cross-functional (e.g., includes members with testing skills, and
others not traditionally called developers: business analysts, designers,
domain experts, etc.)
Plans one Sprint at a time with the Product Owner
Has autonomy regarding how to develop the increment
Intensely collaborative
Most successful when located in one team room, particularly for the
first few Sprints
Most successful with long-term, full-time membership. Scrum moves
work to a flexible learning team and avoids moving people or splitting
them between teams.
6 ± 3 members
Has a leadership role
43. Sprint Planning Meeting
The goal of the Sprint Planning Meeting is to agree on the
sprint goals and negotiate which items from the PBI should be
committed to the Sprint Backlog.
The Product Owner is responsible for declaring which items are
the most important to the business.
The team is responsible for selecting the amount of work they
feel they can implement without accruing technical debt.
The team “PULLS” work from the Product Backlog to the
Sprint Backlog.
The Development team breaks the selected items into an initial
list of Sprint Tasks, and makes a final commitment to do the
work.
The sprint planning is of 8 hours duration for a four week
sprint.
46. Daily Standup Meeting
This meeting is facilitated by the Scrum Master
Time boxed usually to 15 minutes
It is expected that every team member be punctual
in attending this meeting
The product owner however may or may not
participate
Used to answer the following three questions -
What did I accomplish yesterday?
What will I do today?
What obstacles are impeding my progress?
47. Why Daily Standup?
During this sprint items for discussions may arise.
Such items should be listed in a side bar and be
addressed after the scrum meeting.
Why standup meeting?
Promote individual’s commitment to the team
Promote close working relationship
Identify issues in timely fashion
49. Sprint Review Meeting
Why Review Meeting?
Product Demonstration
Status Assignment
Velocity Measurement
Stakeholder feedback
Sprint review typically include the product owner, the
ScrumMaster, development team, and the product
sponsors or stakeholders. This meeting is open to all
stakeholders.
50. Sprint Review Meeting
During the sprint review, the project is assessed against
the sprint goal determined during the sprint planning
meeting. Ideally, the team has completed each product
backlog item brought into the sprint, but it's more
important that they achieve the overall goal of the sprint.
The agenda for this meeting is that the product owner
declares if a sprint backlog is completed or not.
The sprint review is of 4 hours duration for a four week
sprint.
52. Sprint Retrospective Meeting
The sprint retrospective is usually the last thing done in
a sprint.
The entire team, including both the Scrum Master and
the product owner should participate.
The sprint retrospective is of 3 hours duration for a four
week sprint.
The sprint retrospective is a meeting facilitated by the
Scrum Master at which the team discusses the just-
concluded sprint and determines what could be
changed that might make the next sprint more
productive.
54. Sprint Backlog Grooming
The goal of Product Backlog Grooming is to review all the
PBI and rank them so that they can be consumed by the
sprint teams.
This meeting is used to create and prioritize the Product
Backlog Item.
The Product Backlog Item represents User Stories a team
needs to complete.
User Stories are thin, vertical slices of product
functionalities.
The PBI continues to evolve and change as more
information is gathered.
These stories are groomed and prioritized throughout the
project.
57. Release Planning
In Agile, Release is typically defined as the smallest group of
Software features that can be bundled together and deployed
to the users.
Visioning phase
PO and Stakeholders produce a Product Vision and Product
Roadmap
Overall focus is on the Product
The goal is to –
Forecast the delivery timeline of key product increments
and capabilities.
Communicate delivery expectations to Stakeholders.
Communicate the financial impact of the delivery schedule.
60. Steps for Successful Release Planning
Define the Release Goal
Review and Prioritize Backlog Tasks
Estimate the Release
Determine the Number of Sprints
Create a Release Sprint
Identify a Target Date for the Release
Track the progress of the Release
Revise/Update the Release Plan Continuously
62. Estimation
Estimation is the process of finding an estimate, or
approximation, which is a value that can be delivered
by completing any particular task.
Estimation Techniques –
Story Point Estimation
Analogous Estimation
Planning Poker
T-Shirt Sizing
63. Factors to consider while Estimation
Complexity : Consider the complexity of the story
Risk : Consider the team’s inexperience with
developing this story
Efforts : Consider the implementation efforts
Uncertainty : Consider the uncertainty of the story.
64. Story Point Estimation
Story Points is an estimation technique for expressing an
estimate of the overall effort that will be required to fully
implement a product backlog item.
Story points constitute an estimate of the relative size of the
work. This is usually a function of effort, risks, uncertainty and
complexity. It's a high level estimation technique.
66. Analogous Estimation
Analogous estimating is a technique for estimating a variety of
project parameters and measures of scale.
These project parameters can be project cost, project budget,
scope of the project, and expected project duration.
The project measures that can be estimated using this
technique can range from the size of the project to its
complexity.
Analogous estimating is typically a form of expert judgment
that is most reliable when the team members preparing the
estimates have the expertise necessary to accurately do it.
67. Planning Poker
Planning Poker is an agile planning technique aimed at
gaining consensus on the estimated time to complete an
activity.
Team members are given Planning Poker cards with values
like 1,2,3,4 and these values represent the estimation unit
(Story Point).
A user story is discussed and the team members are called
to disclose the duration that an activity is expected to take
by displaying a Planning Poker card.
If all estimators selected the same value, that becomes the
estimate.
If not, the estimators discuss their estimates and the same
process is repeated until the complete team reaches a
consensus.
68. T-Shirt Sizing
T-shirt sizing is a relative estimation technique where t-shirt
sizes, such as XS, S, M, L, and XL, are used to estimate work
items in a seamless way.
It helps teams to understand, discuss, and plan what they
are going to work on next.
70. Scalability
Typical individual team is 7 ± 2 people
Scalability comes from teams of teams
Factors in scaling
Type of application
Team size
Team dispersion
Project duration
Scrum has been used on multiple 500+ person
projects
71. User Stories
Instead of Use Cases, Agile project owners do "user stories"
Who (user role) – Is this a customer, employee, admin,
etc.?
What (goal) – What functionality must be
achieved/developed?
Why (reason) – Why does user want to accomplish this
goal?
As a [user role], I want to [goal], so I can [reason].
Example:
"As a user, I want to log in, so I can access subscriber
content.”
72. User Story
User Story
ID
User Story Acceptance Criteria
US-01 As a User, I want to have a login screen
where I can log into the application using
my credentials: username and password
• A valid user should be able to see login screen
and provide credentials.
• After login, user credentials should be checked
for authenticity.
US-02 As a User, after successful login, I want
to see the main page with header, left,
right panes and logout option.
• A valid user should be able to see Home screen
on successful login.
• User should be able to see header, left and right
panes along with logout option.
US-03 As a User, I should be able to logout
successfully on clicking logout option and
after logout, should see the logout
screen.
• While on main page, user should be able to click
on ‘logout’ button.
• User should be successfully logged out on
clicking ‘logout’.
• User should see logout screen after logout.
• User should be able to login again after logout.
73. Agile Metrics
What are Metrics?
Metrics are measures of quantitative assessment commonly used
for assessing, comparing, and tracking performance in production.
Agile metrics are standards that help the team in monitoring how
productive a team is across the different phases of the
SDLC/PDLC.
We follow Agile so there are specific Agile Metrics like Sprint
Burndown, Sprint Burnup, Velocity, etc. For traditional/waterfall
methodologies, there are different set of metrics like - Schedule
Variance, Schedule Performance Index, Cost Variance, Cost
Performance Index, etc. There are Engineering metrics like -
Automation, Deployment Frequency, Application Crash Rate
(ACR=F/U), etc.
74. Agile Metrics
How does metric help?
Metrics help the team check their performance by measuring how
productive the team is by comparing it with the desired result.
For companies or teams that follow Agile methodologies, agile
metrics help in working on the shortcomings with the help of these
metrics.
75. Sprint Burndown Chart
A burn down chart is a graphical representation of work left to do versus time.
It gives the following info:
Total work at each point in time/ iteration
Remaining story points in tasks
The actual speed of the team
Estimated speed of the team
Benefits of a Burndown Chart:
Status report on the progress of the project.
Having a visual representation of the most important data keeps everyone on the same
page.
It keeps everyone involved and encourages the team to deal with issues before they
become problems. Intended to facilitate team self-organization.
It is the focal point of the workspace, so that it cannot help but direct conversation
towards the project and its progress.
Limitations of a Burndown Chart:
It doesn’t reveal everything.
It does not give any indication of which product backlog items have been completed.
It can be hard to tell if changes in the Burndown chart are because of the backlog items
having been completed or because of an increase or decrease in story points.
77. Sprint Burnup Chart
A burn up chart is a visual diagram commonly used on Agile projects to help measure
progress.
Agile burn up charts allow project managers and teams to quickly see how their workload
is progressing and whether project completion is on schedule.
A burn up chart is better at illustrating the work that’s been accomplished.
78. Velocity
Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key
metric in Scrum.
Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User
Stories.
It gives an accurate forecasting of how many stories a Team can do in a Sprint.
Without Velocity, Release Planning is impossible.
A well-functioning Scrum Team's velocity should steadily trend upward each Sprint.
80. Release Burndown Chart
Progress on a Scrum project can
be tracked by means of a release
Burndown chart.
The Release Burn Down typically
displays the progress of the
current release.
The Scrum Masters should
update the release Burndown
chart at the end of each sprint.
The remaining work can be
shown in whatever unit the team
prefers like story points, ideal
days, team days and so on.
81. Cumulative Flow Diagram (CFD)
The cumulative flow diagram (CFD) measures the state of the work in progress by ensuring
consistency in workflow across the team.
The diagram provides a clear visual representation of bottlenecks. The X-axis represents Story
Points and the Y-axis represents Time.
Ideally, the diagram should be smooth from left to right. Smoothen out the color bands in
case of uneven flow. The band narrowing means throughput is higher than the rate of entry.
If the band widens, this means that your workflow capacity is greater than required, and it
can be moved elsewhere to smoothen the flow.
82. Lead Time & Cycle Time
Lead Time
Lead time determines the time taken by a team to generate ideas, develop and deliver a
working feature of a software product.
In simple words, it’s the time from start to finish that is taken for completing a product or a
service.
If you want to be more responsive to your customers, work on to reduce the Lead time,
typically by simplifying decision-making and reducing wait time.
Cycle Time
Cycle time is a part of the lead time that is taken for developing software and deploying it in
production. In another words, how long it takes you to make a change to your software
system and deliver that change into production.
Teams using CI/CD can have cycle times measured in minutes instead of days.
83. Work In Progress (WIP)
What is WIP limits?
A WIP limit is a cap on the number of tasks your team is actively working on.
It is a fixed constraint on a Kanban board that enables teams to finish the tasks already in the
system before introducing more work.
WIP limits set the maximum amount of work that can exist in each status of a workflow.
Why WIP limits?
Limiting the amount of work in progress makes it easier to identify inefficiency in a team's
workflow.
Without limiting WIP, it’s incredibly difficult to identify wasteful and inefficient processes.
Benefits of using WIP limits
WIP limits enable us to manage capacity.
WIP limits help us identify opportunities for process improvement.
Limiting WIP is one of the most used Kanban Practices
STOP Starting START Finishing
84. Capacity Utilization
Capacity refers to employee capacity (i.e., what is the productive hours for the team).
Capacity utilization determines the percentage of capacity that is being used during a Sprint.
A well-functioning Scrum Team's velocity should steadily trend upward each Sprint.
85. Other Useful Metrics
Sprint Goal Success – Yes/No
Backlog Readiness - [Red/Yellow/Green]
Effort Estimation Variance
Estimated Actual
Over Estimation (E-A/E)*100
Under Estimation (A-E/E)*100
Commitment Reliability - Committed Vs Accepted
Escaped Defects
Defects During Sprint
Defects Post Sprint
Defect Leakage = (Post Sprint defect Count/Defects Detected During Sprint)*100
Delivered Stories Vs Total committed stories
Scope Change
Committed Story Points
Added Story points
De-scoped Story points De-scope Formula = (D/C)*100
Customer Satisfaction - The metric estimates a level of customer’s satisfaction with the product
that varies from very satisfied to very dissatisfied. The data about a level of quality under these
terms is obtained from customer surveys and calculated in percent.
93. Terminology Used in Scrum
Tasks: Added to story at beginning of a sprint and
broken down into hours. Each task should not exceed
12 hours, but it's common for teams to insist that a
task take no more than a day to finish.
Definition of Done (DoD): The exit-criteria used to
determine whether a product backlog item is
complete. In many cases the DoD requires that
all regression tests should be successful.
94. Terminology Used in Scrum
Impediment: Anything that prevents a team member from
performing work as efficiently as possible.
EPIC: Requirement/story for which the effort to complete is
more than one Sprint. They should be split into logical smaller
requirements so that smaller stories can be planned to be
addressed in a Sprint.
MVP (Minimum Viable Product): The total effort a team
is capable of in a sprint. The number is derived by adding all
the story points from the last sprint's stories/features. This is a
guideline for the team and assists them in understanding how
many stories they can do in a sprint.
95. Terminology Used in Scrum
Scaling of Scrum: Usually the Scrum team consists of 7+/-
people; more or less, and the team will not function efficiently.
Now we have a bigger project to execute, how to deal with the
team strength? Here comes the concept of Scaling Scrum,
dividing the project into modules and then having a separate
Scrum team for each module to complete and then finally
integrate all the modules.
Scrum of Scrums: Whenever any technical issue arises, the
Scrum Master will arrange for a team consisting of one key
member from each different Scrum team, and then form a
separate team to analyze and address the issue.
97. Scrum Advantage
Extreme value - reduces risk in ROI
Supports business value driven S/W Dev.
Control of very complex process of product development
Allows Developers to focus on delivering a usable functionality
to the client
Generates productivity improvements by implementing a
framework that empowers teams and thrives on change
Insists that the Client prioritize required functionality.
Ability to respond to the unpredictable in any project
requirements.
Flexibility
Knowledge sharing between Developers
Collective ownership
98. Scrum Disadvantage
Scrum is not effective for small projects
Expensive to implement
Training is required
99. Recommendation
We recommend Scrum as an adaptive and flexible
development methodology that creates a culture of
communication, knowledge sharing and teamwork within an
organization.
• Create a vision.
• Start small - Scrum requires organizational culture change.
• Scrum can be used with any Complex System. It is not
strictly used for Software Development.
• Create a maturity model.
• Never give in to status quo! Scrum is Continuous
Improvement.
• Get an Agile Coach.
100. Books to Refer
Title: The Professional Product Owner
Author: Don McGreal and Ralph Jocham
Title: Succeeding with Agile: Software Development Using Scrum
Author: Mike Cohn
Title: Agile Software Development with Scrum
Author(s): Ken Schwaber, Mike Beedle
Title: Agile Estimating and Planning
Author: Mike Cohn