The document provides a comprehensive overview of the role of a product owner in a Scrum framework, detailing Agile principles, Scrum events, team structures, and estimation techniques. It emphasizes the importance of Agile methodologies in addressing common challenges faced by companies, such as slow time-to-market and low employee morale. Additionally, the document outlines the certification process for Professional Scrum Product Owner (PSPO) and the essential responsibilities of product owners, Scrum masters, and development teams in maintaining an efficient Agile environment.

1. Product Owner in Scrum
Manohar Prasad, PMP®, PMI-ACP®, CAL®, ACC®, CSP®, SA®

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.

11. Agile Trend
Graph Source - http://www.versionone.com/state_of_agile_development_survey/11/

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.]

16. Scrum Framework

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.

18. Scrum Values

19. Sprint

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.

21. Scrum Artifacts

22. Product Backlog & Sprint Backlog

23. Scrum Task Board

24. Product Backlog

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.

28. Scrum Team
Product
Owner
Scrum
Master
Development
Team

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

38. Development Team
Cross-functional (Business
analysts, SMEs, QAs, etc.)
Self-organizing / self-managing,
without externally assigned roles

39. Roles of Development Team

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

41. Scrum Events
 Sprint Planning
 Daily Standup
 Sprint Review
 Sprint Retrospective
 Sprint Backlog Refinement /
Grooming

42. Sprint Planning Meeting

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.

44. Sprint Execution

45. Daily Standup Meeting

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

48. Sprint Review Meeting

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.

51. Sprint Retrospective Meeting

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.

53. Backlog Grooming

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.

55. Product Envisioning in Scrum

56. Release Planning

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.

58. Release Planning

59. Release Planning

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

61. Estimation

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.

65. Story Point Estimation

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.

69. Scrum Team Structures

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.

76. Sprint Burndown Chart

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.

79. Velocity Trend

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.

86. Business Strategy

87. Business Strategy Plan

88. Product Vision

89. Building Right Product
 Stakeholder’s expectation
 Manage Product Backlog
 Clarify Requirements
 Manage Releases
Project Management
 Stakeholder Management
 Requirements Management
 Risk Management
 Cost Management
 Schedule Management
 Project Delivery
Product Management
 Vision
 Domain Knowledge
 Analytical Skills
 Product Marketing

90. Design Thinking

91. Value Driven Development

92. Self-Managing Teams

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.

96. Success Factors

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

101. Questions?
Any questions?