View
219
Download
0
Embed Size (px)
Citation preview
Angeline Aggarwal, CSPO
Product Owner, Tata Consultancy Services
Scrum Gathering India Regional 2013
July, 2013 : +91 99201 37484
What and What NOT! - A PO Introspects
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
ENVISION 1
4 Introspection 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 Introspection 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 Introspection 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 Introspection 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
CREATE A BACKLOG 2
9 Introspection 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 Introspection 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 Introspection 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 Introspection 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 Introspection 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
ESTIMATE 3
15 Introspection 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 Introspection 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 Introspection by Angeline Aggarwal
POs - do not influence the team
USER STORIES EXAMPLES 4
19 Introspection 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 Introspection 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 Introspection 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 Introspection 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 Introspection 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
ALL ABOUT THE SPRINT 5
25 Introspection 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
SPRINT PLANNING 6
27 Introspection 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 Introspection 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 Introspection 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 Introspection 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
SPRINT EXECUTION 6
32 Introspection 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 Introspection 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 Introspection 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
REVIEWS AND
RESTROSPECTIVES 6
36 Introspection 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 Introspection 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
APPENDIX 6
39 Introspection 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