1. Angeline Aggarwal, CSPO
Product Owner, Tata Consultancy Services
Scrum Gathering India Regional 2013
July, 2013
: +91 99201 37484
: angelinepp@gmail.com
What and What NOT! - A PO Introspects

2. 2
A Product Owner is born!
Developer for 7 years
Working on RAD methodology; accustomed to
quick turn-around times.
Suddenly Agile – Alice in Wonderland!
One-week sprints were being followed
enterprise wide – Hit the ground running!
In this presentation……
Scrum flow reviewed
At each step identify
 Common mistakes a beginner
makes
 How they impact the end
result
 How to avoid / become better

3. ENVISION1

4. 4Introspection by Angeline Aggarwal
A vision must be detailed enough to provide clarity…
Why have a vision?
 Guides the team and describes the
essence of the project
 Provides clarity to the stakeholders
that the team has understood what
they have to do!
Attributes of a good vision
 Other Attributes
 Stable
 Clear
 Appealing
 Broad
 Short
 Pass the elevator test
 Demystify the WHO, the WHAT, the
WHY and the HOW
 Who are our customers
 What do they need
 Why do they need
 How we can meet the needs

5. 5Introspection by Angeline Aggarwal
But “Vision” for my first project was woefully incomplete!
Vision for the my first scrum project
To make all finance system applications compliant with new firm wide
change
My Scorecard:
Attributes Score What's the problem?
Who is the
stakeholder
POOR
Team does not know who to turn to, if we run into impediments and
feedback
What are the
customer needs
POOR Unclear: Left open-ended with a catch-all "ALL" systems compliant
Why does the
customer need it
POOR Not identified: Team can't identify with the customers needs
What is the target
time-frame
POOR
Not stated: How do we figure out what resources/time are required and
how much time will be required
Stable POOR The client can go on making continuous changes
Clear POOR Scope left unclear
Short GOOD But its too short, doesn’t cover even the essentials
Broad GOOD Its TOO broad and left open-ended
Engaging POOR Only because it is short

6. 6Introspection by Angeline Aggarwal
This is what the ‘Vision’ should have looked like
Revised Vision
Statement Description
Problem/Opportunity
Statement
 Customer is implementing a new length of employee ids to cater to influx of
new hires
 All downstream applications may not support the increased length
Potential Solution  Test critical applications
 Identify issues
 Fix issues to make the application compliant
Scope of the project  To identify list critical applications which do not have an development team
 Applications which are not to be decommissioned in the next one year
Who is the
stakeholder/Customer
 Program managers (indentified people) for portfolio of applications
Value to the customer  New hires would be able to use applications error free
Timeline  6 months
Success Criteria  Applications should support new length of person id
While it is not short, it is crisp and contains all the relevant information

7. 7Introspection by Angeline Aggarwal
What went wrong
 No clarity on scope / interim
changes
 Not knowing who is involved and in
what capacity
 Not having asked the right questions
Impact
 Improper prioritization of the
requirements/backlog
 Slow the pace in removing
impediments, getting approvals,
requirement clarifications
Doing it right…
 Ask: The more you ask the more you understand. But ask the right questions
 What is more critical
 What needs will it address for the user
 Share the vision with the entire team and make sure the entire team has the
same understanding
 Engage with the sponsor: With the right person at the right time will help in
proper planning and removing most of your impediments in next steps
‘Vision’ - Recap

8. CREATE A BACKLOG2

9. 9Introspection by Angeline Aggarwal
Step 2: Creating a backlog consisting of epics and stories
 The product owner translates the
vision into a backlog
 Product backlog contains the
following:
o Themes/Epics/Stories,
Technical work and defects.
Attributes of a good Product Backlog
 D E E P
 Detailed Appropriately
 Emergent
 Estimated
 Prioritized
 Visible: Readily available to the
team and stakeholders
What is the backlog

10. 10Introspection by Angeline Aggarwal
How I created my first backlog
In my project:
 Each application became an ‘Epic’
 Disregarded the Iceberg: Aiming to break down all the ‘Epics’ into
detailed ‘Stories’ to get to know the overall size of the project
(Waterfall mindset) - Spent two sprints breaking down half the sprints before
checking course
 Two types of stories
 Standard setup stories common for all applications
 Application Specific Stories
 Started implementation of set up stories for couple of applications and
staffed with team
 Project was set up in ‘Mingle’

11. 11Introspection by Angeline Aggarwal
A backlog in disarray
0 1 2 3 4 5 6 7 8-10 11+
Set up
Mingle
Get
Access
App_1
to 10
App_1
Demo
App_1
Story_1
and 2
App_2
Analyz
e Code
App_2
Confir
m
change
s with
User
App_2
Code
changes
. . .
App_2 –
Identify
Testing
Strategy
App_2
-
Testing
App_2 –
Testing
interfaces
(Dependency
came up)
Get
info
App_1
to App
10
Staff
Team
App_1
and
App_2
App_1
Analyze
code
App_2
Demo
and
Analyze
Code
[App_1
contin
ued on
track]
Adhoc
Develo
pment
work
(Added
subseq
uently)
. . . . .
Adhoc
Development
work (Added
subsequently)
. . .

12. 12Introspection by Angeline Aggarwal
Backlog: What was wrong and what was the impact
 Incorrect Prioritization: Too much upfront effort adding details to ‘Epics’ to be taken up much later
 Impact: Effort wasted and re-planning required, big picture missed due to ‘too many items’
 Activity specific sprints: Application 2 was proceeding like a waterfall model within the agile framework
 Impact: Idle time- Developer idle due to delay from user. No back up work planned
 Interdependencies of applications overlooked:
 Impact: Unforeseen delays due to dependencies on teams handling other application
 Ineffective Planning: Should have identified testing strategy upfront
 Impact: Emergency changes in release planning
 Adhoc development work added to backlog – Team ‘Vision’ was compromised. Cascaded into multiple
change requests and additional work
 Impact: Huge delay. Initial user estimate of 2 months took 3 months despite overworked team
 Neglect backlog Grooming: Specific time not allocated for backlog grooming
 Impact: Could not eliminate unwanted items prior to sprint – backlog not ready for next sprint –
resulting in confusion for the team
Overall impact:
 Non shippable deliverables per sprint
 No sign off from the customer
 Overall release getting delayed by 3 months

13. 13Introspection by Angeline Aggarwal
Backlog: Lessons learnt
 Prioritization
 Take up application with most dependencies initially
 Progressively refine – Impossible to think of everything upfront
 Add details Just-In-Time, not weeks in advance because things
change as new information emerges
 Helps avoid too many backlog items
 Stick to the vision:
 Any adhoc requests not in line with project vision should be treated
like a separate project – with its own backlog and stories
 Backlog Grooming
 Would have set aside Time-boxed period for the entire team to
focus on cleaning up the backlog

14. ESTIMATE3

15. 15Introspection by Angeline Aggarwal
Estimation 101
The process of quantifying the effort
required in story points or ideal days
involved in implementing the Product
Backlog with the resources available
What is Estimation
The WHEN, WHO And HOW of Estimation
 The When:
 Before the first sprint
 During the first 2 sprints
 On going
 Who: Product Owner + Scrum Master + Team
 The How
 Story points vs. ideal days
 Planning poker
End Result
 Sized Stories
 Results in backlog refinement

16. 16Introspection by Angeline Aggarwal
What were the mistakes Impact How to avoid them
Playing the task master:
• Product owner drives estimate
based on deadline of the
project
• Team estimated 3 weeks I
pushed for 2. It finally took 3
weeks
• OR Team compromises on
Quality
Estimate should be Honest not
influenced:
• Developer should give the
estimate not the product owner
• Scrum master to facilitate
Equating story points to days:
• Each story is considered
individually rather than a
collection to relative estimate
• Failed to see big picture
• Overall deadline slippages
•Play the poker - Its fun!
Trying to estimate the
inestimable!
• Stories are too complex or too
many unknowns/dependencies
to estimate
• Radically different estimates
from team members due to
different interpretations
• Extended planning duration
• Stop and think and break down
further
lUnclear Scale:
lTeam not clear on the scale
being used
• Use a scale which all team
members identify with
• Identify smallest and largest at 2
points and 20 points respectively
Chasing Velocity:
Adjusting estimate to meet
forecasted velocity
• Slippages across sprint
deadlines
• Over-worked team –
unsustainable in the long run
• Velocity gets derived from the
estimates and not the other way
around
Common pitfalls and how to avoid them

17. 17Introspection by Angeline Aggarwal
POs - do not influence the team

18. USER STORIES EXAMPLES4

19. 19Introspection by Angeline Aggarwal
Backlog consists of multiple USER stories
 Defining the deliverables from a users perspective aligns with goal of the product
 Format: As a <USER>, I want <SOMETHING>, so that <SOME VALUE>
o For Technical stories, user is replaced by the module
Define from a “USERS” perspective
Attributes of a good Story
 I N V E S T
 Independent
 Negotiable
 Valuable
 Estimable
 Small
 Testable
 Should define the WHO, WHAT and WHY
 Story should contain acceptable criteria (for validation) - Sufficient to define
the boundaries of the story

20. 20Introspection by Angeline Aggarwal
Its time to write a story: User Story 1
User Story:
Add a share activity
section to the share
activity report to display
share transactions for a
user
Acceptance criteria:
Display share activity
information in the
following columns, no of
shares, date, activity (Buy
or sell), quantity, value
per share and total
amount
User Story:
As a user, I want to see the share
activity details, for the selected
person for the current financial
year, so that I may view the
details of the share transacted
by that user and compute share
balance
Acceptance criteria:
Display share sale and share
purchase in separate rows with
the following information, no of
shares, date, activity (Buy or
sell), quantity, value per share
and total amount in a user
defined format
Should have
been

21. 21Introspection by Angeline Aggarwal
What were the mistakes Impact How to avoid
mistakes
The
“WHY” is
missing
Story defined from a
developers perspective of what
needs to be done, not the why
Impact: If we knew what we
wanted to use the report for,
we could have added additional
data useful for user (like total
gain in the period, etc)
Could have suggested
displays with additional
data would could have been
meaningful to the user
Potential Additional
revenue lost?
Ask more
questions with
the
stakeholder
and constantly
engage
The WHAT
not
completely
defined
Report pertains to which year –
what test data to retrieve
NOT testable. Boundary
condition missed out.
Involve the
team in story
writing
Not
negotiable
User wanted a different format
for a boundary condition
(shares bought and sold on the
same date in separate columns)
Could not be completed in
simple sprint.
Code had to be re-worked.
Few person days additional
required
Describe by
examples
User could
have pointed
what he
wanted
Analysis of User Story 1

22. 22Introspection by Angeline Aggarwal
Story..continued..: User Story 2
User Story:
As a user, I want to run the
report X for multiple
employees in a given date
range
Acceptance criteria:
 Report should accept
multiple employee
numbers in a comma or
space separated string
 User should be able to
enter start and end date
User Story:
As a user, I want to run the
report X for multiple employees in
a given date range so as to be
able to generate a batch of
reports of all employees under a
partner at one time
Acceptance criteria:
 Report should accept multiple
employee numbers with a
minimum of 750 in a comma or
space separated string
 User should be able to enter
start and end date
 The entire report should be
generated in a maximum of 30
seconds
Should have
been

23. 23Introspection by Angeline Aggarwal
What were the mistakes Impact How to avoid
mistakes
The
“WHY” is
missing
Lead to unclear boundary
condition below
Focus on
discussion
rather than
documentation:
Ask more
questions and
constantly
engage with the
user
ilities and
UI
constraints
Boundary condition not
defined:
User wanted to run report for a
minimum of 750 users at one go
Performance tuning
(optimization) was not
done
Architecture reworked for
optimized performance
Missing
definition
of done
How long should the report
generation take was not listed
The entire report could
not be done in 30 secs as
required by the user, had
to increased up to 2 mins
Analysis of User Story 2
Is it possible to write a complete story upfront and ready for a sprint - NO

24. ALL ABOUT THE SPRINT5

25. 25Introspection by Angeline Aggarwal
Sprint away!
 A time-boxed period during which the scrum team works to build a potentially
shippable increment to the product
 Both incremental and iterative at the same time
 Iterative - Planning + Execution + Review
 End result: Potentially shippable increment to the project / product
Deliver at end of each sprint: Allows to inspect and seek constructive feedback

26. SPRINT PLANNING6

27. 27Introspection by Angeline Aggarwal
What is Sprint Planning
 Entire team (Product Owner, Scrum
Master, Developers, etc) participate in
the Sprint planning meeting to discuss
the following
 Sprint goals
 Selection of sprint backlog for the next
sprint (Backlog items that the team
commits to and the tasks they are
broken down into)
 Typical effort of two-four hours per
sprint
What happens during Sprint Planning
Outcome of Sprint Planning
 Defining what the team will achieve in the next
sprint
 Shippable increments
 Behind-the-scenes features
 Just something valuable
 Further break down stories based on new details
 Emergent requirements

28. 28Introspection by Angeline Aggarwal
Sprint Planning Case Study
Top Story Priorities
Stories Points
App_2 Testing (Modules 01 to 10) 3
App_2 Testing (Modules 11 to 20) 3
App_2 Testing (Modules 21 to 30) 3
Test App_2 Interface 1 5
Test App_2 Interface 2 5
Capital Tax Report
(became a 20 pointer
subsequently)
8
App_3 Analyze Code Base 3
App_3 Get Access to Dev Env. 2
App2_Analyze Back end 3
App3_Analyze Import Module 3
App3_Upload 2
App3_Sumbit 3
Chasing too
many points
per sprint
Interface
modules should
have been
prioritized over
• Story too big
to be taken
up and
therefore
broken down
• Task based
break down
into :
Analyze the
requirement,
etc
Detailed plan
for all the
activities put in
place much in
advance

29. 29Introspection by Angeline Aggarwal
Sprint Planning Mistakes Impact How to avoid mistakes
Lacking the big Picture:
• Selecting stories with a
short term goal in mind
• In-correct prioritization
and thereby selection of
sprint
• Start with a prioritized backlog
• Always first take stories which
have maximum
interdependency
Waterfall in Agile
• Planning activity specific
sprints rather than holistic
development of an
increment
• No user specific
deliverable
• Risk of spending too
much time for one
activity which doesn’t
get validated
• AVOID the temptation and
ALWAYS deliver at-least a
testable increment
Chasing Velocity
• Over-committing or
selecting stories that are
too large for the sprint
Planning for overwork
“Need to complete at least
14 story points to maintain
our velocity”
• Overworked team
• Compromise on testing
and quality OR
• Under deliver in next
sprint
• Plan based on what can be
completed end to end
• Selecting the right mix of
stories – not all large, not all
small
• Achievement is not in terms of
velocity – velocity should result
from doing scrum right
Planning for a better finish

30. 30Introspection by Angeline Aggarwal
Sprint Planning Mistakes Impact How to avoid mistakes
Scheduling issues
• PO/ Team member is not
available for the
meeting
• Team members
don’t understand
the sprint goals
• Be flexible with scheduling
• Make the planning meeting
compulsory to all
lPlanning too much into
the future
• Little room for
progressive
adjustments,
• Leads to effort
waste
• Product Owners! Know your backlog
• Plan at the optimal time – one or two
sprints in advance
Starting the new sprint
with planning
• Should be done 2 days
before next sprint starts
• Result in idle team
• Lead time to get
At least 5-10% of team time should be
reserved for planning for the next
sprint
Ignoring Team Ability /
Availability
• Leads to over
committing and
under-delivering
• Avoid assigning story to individuals,
assign story to a team / sub team
• Opt for pair programming where-ever
critical
• Product owner should be aware of
team absences and take that into
account
Think holistically – don’t lose track of the overall vision

31. SPRINT EXECUTION6

32. 32Introspection by Angeline Aggarwal
Are we getting there? Can you see the goal?
 Team works on the backlog items
committed for the sprint
 Mode of operation:
 Time-boxed daily scrum
 Task boards
 Impediments list
 Changes in boundary conditions –
decide on whether to terminate
the sprint

33. 33Introspection by Angeline Aggarwal
Sprint Execution
Mistakes
Impact How to avoid mistakes
No daily scrum
• Inconsistent meeting
times
• Skipped meetings
• Difficult to understand team
progress
• Individual follow up with team
members – waste of time.
• Team unaware of each others
work and possible impact to
their story
• Disciplined daily scrum
• Fixed meeting time and place
Lack of enthusiasm
• Team not fully
involved
• Meetings from their
desk /
simultaneously doing
other work
• Loose an opportunity to see
overall progress, give and
receive inputs
• Just focused on status updates
• Daily Stand-up done right!
• Time-boxed no lengthy
discussions
• Accounting for time
during DSM rather
than goals and
achievements
• Developer may have spent a
day on the story but achieved
nothing in terms of value
• Updates should be in terms of
what was done and not how
much time was spent on it
Sprinting away from the goal and how to avoid it

34. 34Introspection by Angeline Aggarwal
Sprint Execution
Mistakes
Impact How to avoid mistakes
No mid sprint checks
• Items left for
implementing at the
end – not mid-sprint
checks
• Compromised on scope and
quality
• Maintain Sprint Burn down chart
• Not a time for troubleshooting
• Reduce wasteful effort –
automate where possible
• Don’t leave testing for the end –
it generally gets skipped
• Changing the sprint
goal/sprint backlog
during the sprint
• Hampers the team’s focus
and rhythm
• Leads to hasty and
unplanned activity
• Avoid changes to the sprint goal –
what to do if the priority of
backlog suddenly changes?
lImpediments
• Not raising / handling
impediments
• Delays
• wasted effort
• Slippages
• PO should follow up / force /
beg for team to come up with
impediments
• Make the team comfortable to
escalate issues
Sprinting away from the goal and how to avoid it

35. REVIEWS AND
RESTROSPECTIVES
6

36. 36Introspection by Angeline Aggarwal
A great finish! – Reviews and Retrospectives
Objectives of the Sprint Review
 1 hour per sprint: Set aside to reflect on
the sprint gone by
 Start, Stop, Change, Continue
 Setup and continually improve best
practices
 No retrospective
 A missed opportunity to learn
 Repeat the same mistakes
 Keep it informal
 10-15 mins per Sprint to Inspect and Adapt
 Highlight team goals and achievements
 Assess the achievements against the sprint
goal and not just completion of backlog
 A natural end to the sprint, not a
distraction requiring preparation time
Retrospective: Learn from the past

37. 37Introspection by Angeline Aggarwal
Maintaining a sustainable pace of development
Pace yourself like a marathon runner;
Get a head start, go steady in between &
Towards the end, give it your all
 Start Small but think Big – never forget the big picture
 Use same length sprints - helps planning and the team works with Rhythm
 Focus on delivery – Definition of done – complete story
 Continuous improvement
 Don’t bank on overtime – it cannot be sustained
 Refine the plan – adjust to accommodate changes in scope, time
 Never compromise on quality
 Maintain agile discipline

38. APPENDIX6

39. 39Introspection by Angeline Aggarwal
References
 http://agile.dzone.com/news/retrospect-about-sprint
 http://www.slideshare.net/Conscires/sprint-execution-standup-taskboard-etc
 http://www.slideshare.net/romanpichler/product-backlog-tips-and-tricks
 http://www.slideshare.net/dhaval.r.panchal/keeping-product-backlog-healthy
 http://agilepainrelief.com/notesfromatooluser/2012/06/scrummaster-tales-learning-how-
to-estimate.html
 http://colearningbe.wordpress.com/2013/04/01/most-common-mistakes-in-scrum-
ceremonies-27-estimating-stories/
 http://scrummethodology.com/scrum-effort-estimation-and-story-points/
Websites
Book
 ‘Succeeding with Agile’ by Mike Cohn