2. 2
Agenda
• Agile Transformation with a Product Owner Perspective
• Role of Product Owner with respect to Team
• Top 10 deliveries of a PO
• Product Backlog Grooming
• Techniques for Grooming your Sprint
• Sprint Zero
• Release Management
• Next Steps…
7. 7
Daily Standup
• Iterative-Incremental. Accept that
change is natural
• Structures development into small
self managing and cross functional
teams
• Selects work from a prioritized
backlog and commits to complete
them by end of the Sprint
• Each day the team gathers for a 15
mins stand up meeting to report
their progress to others. “Inspect
and Adapt”
10. 10
Product Owner
Owns the vision of the product
Creates, owns and maintains the PBL
Defines the “Sprint Goal”
Prioritizes the PBL according to business
value
Represents the interests of customer and
engaged with stakeholders
Elucidates Epics, themes and features
and converts into user stories
Decides on the course of the project at
beginning or sprint “Grooming”
Supposed to have extensive domain
knowledge
Inspects the work done by the team and
determines the DOD
Is available in all Sprint ceremonies
11. 11
Roles of a Product Owner
Find
Market
needs Prepare
business
cases
Write biz
requirement
s
Prioritize
development
Build the
Sales pitch
and train
them
Deliver a
winning
product
Attend
sales
calls
Perform
analysis
13. 13
Top 10 Deliveries from Product Owner
1. Initiate and translate product road map into manageable
product backlog
2. Define the acceptance criteria and DOD for features
3. Manage, adjust for risk, and prioritize product backlog
4. Be available for team in all the Scrum ceremonies
5. Manage product dashboard and communications to internal
teams
6. Understand the primary activities and supporting process
activities for value maximization
7. Understand Agile estimation approaches and allow the
team to manage itself
8. Pull the team to maintain continuous velocity stream,
ensure quality, eliminate escaped defects, and motivate
team
9. Familiar with the organizational development practices,
platform requirements and project management framework
10.Operationalize the product into the mainstream
organization focusing on sales-to-implementation efficiency
14. 14
3 C’s of User Stories
• Card
• Stories are written on
notecards and maybe
annotated with estimates
• Conversation
• Details of the story are
outcome of conversations
with Product owner
• Confirmation
• Acceptance test confirm
the story has been coded
to specification
15. 15
Why User Stories ?
• User stories are easily
understandable
• Developers and Customer
understand stories better
• The focus is shifted from writing
long specs to talking
• It is better to understand event if
organized into stories
• User Stories Support and
encourage Iterative development
• Epics >> Theme >>User Stories >>
Tasks >> Subtasks
17. 17
5 W and 1 H (Six Sigma Approach)
o Who ( Persona )
o Who are the target customers of your product
o What ( Problem )
o What challenges are customers facing with
current products in market
o When (Goal )
o When do customers use our product
o Why ( User Scenario )
o Why customers will use our product
o Where ( Requirement )
o Where will you position the product
o How (Specification )
o How will you market the product in the market
19. 19
Backlog Grooming and its rules
• Improving the product backlog by
prioritizing the work items
• This is a meeting between
developers and the product owner
• Grooming is a continuous activity
• Focus is on the current srint and two
sprints ahead
• This is a collaborative timeboxed
meeting with focus on continuous
improvement
21. 21
Product Backlog and its Prioritization for Sprints
21
High risk
Low value
(Avoid)
High risk
High value
(Do first)
Low risk
Low value
(Do last)
Low risk
High value
(Do second)
Risk
Value
high
Low high
23. 23
Scrum Master
Facilitator and Servant Leader
Mentors team on practice
Removes Impediments of the team
members
Shields the team from external
influence
Mediate and resolves conflicts
Gets “DOD- Definition of done”
finetuned from Product owner
Monitors and tracks burndown charts
and JIRA Board
Reflect on performance feedback and
focus on Process improvement
Celebrates team success
24. 24
2 Week Sprint (Dev and QA)
Sprint Length is 2 weeks
Concept of Pigs and chicken (involved vs
committed)
The Sprint starts with a Sprint planning
ceremony where tasks are selected to be
executed on Sprint
The team commits to a fixed time of
availability of the team members within
the Sprint
Top priority and high risk items are taken
first and worked upon by the team
Concept of “Fail fast” or “ Fail early” is
adopted by the team
There are various estimation techniques
available for the team to factor Sprint
work items (XL Sizing or Parametric
estimation)
Having a “ Burn down Chart” on team
rooms
25. 25
Prudent Practice (Sprint Planning)
Backlog Grooming to be
prepared for well in advance
by Product Owner
Know your team capacity for
the current sprint factoring
member availability to serve
as a guideline for task
estimation
Don’t fill to Capacity. Always
leave room for unknowns that
come up
27. 27
Release Management
Breaks down Vision, roadmap, epics into defined
releases
Product owner does Release planning and
management along with Product council
At ECL we do approximately one release per quarter
A Release has incremental functionality developed
with updating of SQL
Determine the no. of sprint iterations within a release
Participating in “Inspect and adapt” approach to
improve value stream
Planning the PBL to scope for new issues,
dependencies, overlaps and gaps in product vision
Product
Backlog
Release
Backlog
Sprint
backlog
28. 28
Mapping your stories to Releases
Backlog Grooming to
be prepared for well in
advance by Product
Owner
Know your team
capacity for the
current sprint factoring
member availability to
serve as a guideline
for task estimation
Don’t fill to Capacity.
Always leave room for
unknowns that come
up
29. 29
Sprint Retrospective
Greatest advantage of Agile adoption
Works on the principle of “Inspect and Adapt”
5 top level questions that team deliberates on
What went well ? (Start positive) We should
continue doing
What have we learnt from the current sprint ?
What didn’t go well ? How do we improve on
that ?
What we need to stop doing ?
Star fish approach to retrospectives
Incorporate these input into subsequent
Sprints
30. 30
Ways Agile adoption can fail
Product Owner is not available to
clarify requirements
Product Owner micromanages the
team
Adding new tasks at the middle of the
sprint without team agreement
Scrum master assigning work to the
team
Not everybody in the team available
for standup meetings
No clarity on the definition of done