This document discusses agile planning techniques, including estimating story sizes using planning poker. It recommends that the product owner have all stories sized before the first sprint using planning poker to estimate relative sizes quickly and without bias. The product owner can then use these estimates to create a release plan and update it during sprints as new stories are added or split. It also discusses when stories should be re-estimated, such as when their relative size changes or when goal-level stories are split into smaller stories. Velocity is also discussed as a way to estimate future sprints based on the team's past performance.

1. Agile Planning
Presented by Juan Banda

2. Time vs. Size
Time is not visual Size is
2

3. Why do we estimate
size?
•Time-based
estimates depend
on who does the
work
•Size-based are not
biased by individual
judgment
•Using size-based
estimates provide
also estimates about
relative complexity
3

4. Relative size
estimation
•Independent of who
implements
•Sizing is easy, relative
to baseline and other
stories
•Planning Poker scale is
suitable for humans
•Fast 20 stories / hour
•Accurate ‘Planning
Poker’ combines Delphi
wideband with expert
estimating
4

5. Planning Poker
•This very simple technique
needs that all team
members vote –using cards
or paper slips– about the
size they think a user story
has
•No talking in the first
round, just voting
•The ScrumMaster ask
questions to the ones that
vote extreme values
•A second round is called
•Mean or mode values are
assigned as user story
sizes
5

6. Velocity
• What is velocity?
•Rapidity of motion
• Why use it?
It help us to
•
estimate next sprints
•3 Sprints rule
•Initial estimates
6

7. When should we
estimate?
PO should have team size all
•
known stories for entire release
prior to first sprint
•Do this as part of the story-
writing workshop
•Need sizes to create a
release plan
•PO should call an estimation
meeting during each sprint for
the team to size new or split
stories for up-coming sprints
•Update release burn down
chart with changes to the
release backlog
•Team must allow time
during the sprint for this—
typically 1 or 2 time-boxed
meetings per sprint
7

8. When should we
re-estimate?
Actual velocity is lower than
•
estimated
•Velocity will automatically
correct underestimation, no
re-estimation needed
Team changes
•
Velocity will reflect any
•
change in capacity, no re-
estimation needed
Goal-level or epic story is split
•
New ‘child’ stories must be
•
estimated (independent of
original story size)
•Relative size of story changes
(new understanding)
•Story should be re-estimated
relative to other (known)
stories
8

9. Release planning
•With all the user stories
estimated using planning
poker, the PO can work on
a general estimate for when
the project will be delivered
•This is not fortune telling, it
can be err by some factor
but its not a wild guess
•Research shows that
planning a release using
this technique is as much
as accurate as any other
estimation based on
mathematical models, but
times cheaper in time and
resources
9

10. Thanks for attending