AGILE

PLANNING & ESTIMATING

WEBINAR
2018
Agenda
• Why plan?
• What is an agile plan?

• Product backlog estimation

• Ideal time
• Story points
• T-Shirt Sizing

• Levels of planning / precision

• Iteration or sprint planning
• Release planning
 PLAN
VS.
PLANNING
Why do we plan?
“Cone of uncertainty”
• Support reliable decision-making!

• A good plan will have multiple levels:

• We’ll be finished in fourth quarter
• We’ll be finished in October
• We’ll be finished October 9th.
What is an agile plan?
• Focused on planning instead of the plan
“The planning onion”
• Encourage change
• Results in plans that are easily changed
• Planning is recurring throughout the project
• Planning is done on different levels
 MEANS
OF
ESTIMATION
Ideal time (days)
• It’s the number of days something would take if
• Everything you need is available
• It’s all you are working on
• You will have no interruptios
• Example:
Ideal time of a NBA basketball game is 4x12 minutes and 15 minutes half time.
In respect to elapsed time which is normally around a 120 minutes average.

My Ideal time is different than your ideal time (within a team)

Ideal time IS easier to explain outside the team
Ideal time IS easier to estimate at first
Story points
• Story points are estimates of the efforts to complete a story, influenced by
• Amount of work to do (The “Bigness” of a story)

• Complexity of the work

• Any risk and/ or uncertainty doing the work
Be aware: always the combination of the above!

• The is NO unit involved specifically not TIME!

• Story points are based on RELATIVE ranking

Relative Ranking

Estimate these ...

What does this mean for estimating user stories?
• Create a “known by the team” user story as benchmark.
• Compare a “known by the team” user story to new stories.
• Build up a team story reference board (Wall of reference).

5
One way of estimating of user stories: Planning Poker!
Planning Poker
• Each estimator is given a denk of cards

• Customer / Product Owner introduces a story/ feature and it’s discussed briefly

• Each estimator selects a card that’s his or her estimate, hidden!

• Cards are simultanously turned over so all can see them

• Discuss differences (especially outliers)

• Re-estimate until estimates converge

Planning Poker Exercise
Product backlog item (story) Estimate

1. Read a high-level, 10-page overview of scrum in popular magazine.

2. Read a densely written 5-page research paper about the people influencing
forces within a scrum implementation in an academic journal.

3. Write the product backlog for a simple eCommerce site that sells only NFC
chips.
4. Recruit, interview, and hire a new team member for your squad.

5. Host a 45 minute session, including a 30 minute presentation, about scrum

for your co-workers.
6. Wash and wax you boss’ car.

7. Read a 200-page book on scrum.

8. Write an 5-page summary of this webinar for your boss.

exercise @ planningpoker.com
Why planning poker works?
• Those who will do the work, estimates the work.
• Estimators are required to justify estimates.
• Discussion on common ground, not on specific expertise.
• Combining individual estimates through group discussion leads to better
estimates.
• Relative rather than absolute estimating (faster).
• Everyone’s opion is heard.
• It’s fun! “Planning poker estimation is a means, not the goal”
T-Shirt sizing
• Also a “relative” estimation technique
• Prevents over-analyzing (risk with points)
• Often used on epic or theme level (very big stories)
• Often used to quickly estimate a complete backlog
 PLANNING
(BOTTUM-UP)
Daily planning (the scrum or stand-up)
• Examine plan on task/story level
• What will we “as a team” do the upcoming 24 hours.

• Step 1: Gain insight, where are we standing towards our sprint goal and
stories
e.g. What did i do last 24 hours .... What will i do upcoming 24 hours ... Am I hampered ...

Step 2: Must we adjust our plan for this sprint?

e.g. Are all stories feasible? Can we add one more? Must we communicate change ...?
Iteration (sprint) planning
• 2 approaches

• Velocity-driven sprint planning

• What is our velocity?
• Add stories to comply with this number
• Needs time to establish a trustworthy figure
• So only usefull over the long term
• Fast! Team
velocity
= 14
• Commitment-driven sprint planning
• Discuss highest priority story
“Creating the sprint backlog during
• Decompose in tasks and estimate hours iteration (or sprint) planning”
• Are resources available? Can we commit?
• if yes next backlog item
• If not evt. Smaller backlog item or we’re done “Be aware on personal availability!”
• Takes more time
Release planning
When will this
• Detailed breakdown of the entire epic (or
part of the project feature/ theme/ initiative/ project) into
be done? realizable user stories.

• Team agreement on estimation of user

stories (ideal days/ story points/ t-shirt).
Can we do these
two initiatives
simulationiously?
• Reliable velocity measurement over at
least 3 sprints and a calculated minimal
and maximal achievable amount.

How much of this

• Extra time investment for ‘mega-
will be done before refining’.
end of june?
Step 1. Estimated backlog (or release backlog)
• So have a clear estimation of the part
of the backlog you want plan.
• Total backlog
• MVP backlog
• Release backlog

• Estimation is done by the team!

• Refinement will cost (a lot of) time!

So plan ahead
Step 2. Determine team velocity
• To do a release plan you need insight on your teams’ velocity

• 3 ways to get team velocity

• Use historical averages of the teams’ velocity (most accurate)
• Run 2-3 iterations and see what you get (less accurate)
• Forecast it (least accurate)
Team A
Velocity
• Determine median velocity. predictable

• Put, based on predictability, a 90%

till 70% confidence interval around it. Team B
• Determine “best case” and “worst case”. Velocity less
predictable
Step 3. Calculate number of sprints
Based on estimation & velocity you are
able to predict number of sprints needed.

You can do this for a worst case,

best case or most likely scenario.

“Be aware this is a planning!”

Ongoing monitoring and progress will give more insight
and will make remaining plan more accurate
Story points based “duration estamination”
Estimated size of Provides the answer to the question:
the current backlog “When will it be finished”

Size Calculation Duration

200/20 =
200 points Velocity = 20
10 iterations
velocity is simply a measure of
how fast a specific team is going
Step 4. Divide the work into portions per release or per
sprint Sometimes a Product Owner and/ or a team wants to plan sprints ahead:
• to feel more comfortable in completing their goal,
• being transparant in communicating their planning,
• keeping stakeholders aboard
• or a combination of these ...

Be aware, this is a TEAM activity

• They know content
• Evt. dependencies
• Availability
• Etc.

Keep in mind!
you don’t know everything yet,
keep some ‘slack in your sprint’
Some related metrics & measures
QUESTIONS?