Materials Licensed from BigVisible Solutions Training Solutions Agile Planning v. 7.7.1

Materials Licensed from BigVisible Solutions

Training Solutions

Agile Planning

v. 7.7.1

Agile Estimationand Planning

2

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____

Click to edit Master text stylesSecond levelThird levelFourth levelFifth level


Dilbert on Project Planning


3

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Agenda

► Planning Planning Wisdom Traditional Planning Agile Planning 3 levels of Agile Planning

► Agile Release Planning Backlog Prioritization Story Sizing Creating the Release Plan Maintaining the Release Plan

► Agile Iteration Planning Commitment-base Iteration Planning Velocity-based Iteration Planning


4

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



“A good plan executed now is better than a perfect plan executed next week.”

-General George S. Patton

“Planning is everything. Plans are nothing.”

-Helmuth Graf von Moltke (Prussian Field Marshal and strategic military thinker)

“If you tell people where to go, but not how to get there, you’ll be amazed at the results.”


Planning WisdomPlanning Wisdom


5

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



►Planning by activity rather than by feature Lateness passed down schedule

►Multitasking Negative effects on productivity are typically not accounted for

►Features not developed by priority Important features often left until later and dropped if schedule not met

►Uncertainty is ignored Development is highly dynamic endeavor

►Estimates become commitments and are used against developers These usually start as “guesstimates” but later perceived as promises

Why do some traditional plans fail?


6

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



►Parkinson’s Law Work will fill the amount of time allotted to complete it

►Student Syndrome Work will not begin until the latest possible opportunity

Why do traditional plans fail?

Task Safety

To have ANY chance of doing better than plan, developers must focus on completing task immediately.

Traditional plans identify activities and completion dates.

TaskSafety

In reality, however, we procrastinate and don’t start the task until we feel there is just enough time left to get it done


7

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Planning to do our worst

► “…if all goes perfectly…” Activity based planning using Gantt charts allows us to only meet deadlines if

all goes perfectly

► Adapts poorly to the reality Poor ability to adapt to changing situations Poor ability for targeted learnings

► Any slip in any task affects all subsequent tasks Assumes that a slippage is localized and atypical

► Activities will start as late as possible (Student Syndrome) Reduces ability to respond to change

Using traditional planning methods, we are “planning to do our worst”


8

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



What is a good plan?

► A good plan is one that supports reliable decision-making

► One that increases in accuracy and precision over time We’ll be done in the fourth quarter We’ll be done in November We’ll be done November 7th

“It is better to be roughly right than precisely wrong.”

-John Maynard Keynes

“It is better to be roughly right than precisely wrong.”

-John Maynard Keynes


9

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



► Focus on planning – not the plan

► Balance benefit and investment

► Adaptive to change and learning

► Plans are easily changed

► Planning is continuous throughout the project

What makes planning Agile?


10

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Different levels of planning

Strategy

Portfolio

Product

Release

Iteration

Day

We will focus on these 3 planning areas


11

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



3 Levels of Agile Planning

Iteration

1

As an investor, I want to…

3


5

Iteration

2


5

As a visitor I want to…

1


2

Iteration

3


3


3

An investor I want to…

2

Release Backlog (Stories)

Define test cases 4

Code UI 8

Code middle tier 12

Code stored procedures

12

Automate tests 6

Iteration Backlog (Tasks)

“Yesterday I started on the UI, I should finish it today”

Daily Stand-up

Release PlanningIteration PlanningDaily Planning


12

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Release Planning


13

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Release Planning

Q. What do we need to start Release Planning?

A. List of prioritized stories aka. Release Backlog aka. Project Backlog aka. Product Backlog

The same techniques for a single release can be applied to multiple releases to derive a multi-release project plan

Priority Story Size

1 As an investor, I want to…



4 As a visitor I want to…




8 An investor I want to…

Release Backlog

We don’t need ALL possible stories – just enough to at least roughly fill the desired timeframe

Team Velocity Use Historical Values Use Actuals by running an iteration Forecast or Derive


14

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Prioritization


15

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Prioritization Factors

► Financial Value of stories/features Assign dollar-value to stories or features

► Cost of implementing (or not implementing!) stories/features Consider cost now vs. cost of adding later Also consider opportunity costs

► Amount and significance of learning and new knowledge created by the stories/features

Project (how?) Product (what?)

► Amount of risk removed by developing the stories/features Reduced project or product uncertainty

► Prioritize across “Themes” or “Features” individual stories that cannot clearly be “valued”

Note:As long as the Product Owner is considering all these things appropriately, there is no need to formalize or overcomplicate prioritization


16

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Risk

Anything that might happen that would jeopardize or limit the success of the project.

Types of Project Risk:

► Schedule Risk “We might not be done by October 21”

► Cost Risk “We don’t have budget for more consultants”

► Functionality Risk “We might not be able to develop sufficiently-flexible roles-based access”

Note:Though technically “Risks” can have positive as well as negative impacts on projects – however typically the word “Risk” is not used to describe possible positive effects. As such, we will focus on the negative impact of “Risk”.


17

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Risk-Value Prioritization

Which stories should we work on first?

High Risk

Low Value

High Risk

High Value

Low Risk

High Value

Low Risk

Low Value

Ris

k

Value

High

LowLow High

Tackle high-risk areas with big return.

These likely aren’t worth doing EVER.


18

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



More about Prioritization

► Financial New Revenue, Incremental Rev, Operating Efficiencies Net Present Value, Internal Rate of Return, Payback Period, Discounted

Payback Period

► Desirability Must-haves The More, the Better Exciters

“The indispensable first step to getting what you want is this: Decide what you want.”

-Ben Stein

“The indispensable first step to getting what you want is this: Decide what you want.”

-Ben Stein

MoSCoW Prioritization TechniqueMust Haves - Fundamental to the projects success o

Should Haves - Important but the projects success does not rely on these Could Haves - Can easily be left out without impacting on the projecto

Won't Have - This time round can be left out this time and done at a later date

MoSCoW Prioritization TechniqueMust Haves - Fundamental to the projects success o

Should Haves - Important but the projects success does not rely on these Could Haves - Can easily be left out without impacting on the projecto

Won't Have - This time round can be left out this time and done at a later date


19

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Story Sizing


20

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Imagine…

► You are fed up with software development

► And you decide go into the landscaping business

► Your first job:

Move this pile of rock from the front of my house to the back

How do we estimate how long?


21

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



How might you estimate this?

► One way: Look at the pile of rock and estimate

how many wheelbarrow loads it represents

After an hour, see how many wheelbarrow loads have moved

Extrapolate the total duration

• I think that’s 100 wheelbarrow loads• After an hour I’ve moved 20 loads• So, I should be done in a total of 5 hours

• I think that’s 100 wheelbarrow loads• After an hour I’ve moved 20 loads• So, I should be done in a total of 5 hours


22

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Estimate Size – Derive Duration

SizeSize Velocity Calculation

Velocity Calculation DurationDuration

250 pounds250 pounds Velocity = 50 PoundsVelocity = 50 Pounds

250/50 = 5 trips

250/50 = 5 trips

120story points

120story points

Velocity = 20 PointsVelocity = 20 Points

120/20 = 6 Iterations

120/20 = 6 Iterations


23

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Sizing Release/Product Backlog

Iteration

1


3


5

Iteration

2


5


1


2

Iteration

3


3


3


2

Product Backlog (Stories)

Define test cases 4

Code UI 8

Code middle tier 12


12

Automate tests 6


Story Points orIdeal Days

Hours

We are talking about these

right now


24

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Measures of Size

► Traditional Measures of Size Lines of Code Function Points

► Agile Measures of Size Ideal Time Story Points

► Traditional and Agile measure size differently






25

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Ideal Time

► How long would something take if: It’s all you worked on You had no interruptions Everything you need is readily available

► The Ideal time of a football game is 60 Minutes 4 x 15-minute quarters

► The elapsed time is much longer (3+ hours)

► Shortcomings of sizing with Ideal Time My ideal days cannot be added to your ideal days Ideal days are often confusing and misleading because they do not represent

duration Ideal Time is dependent on the implementer


26

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Elapsed time vs. ideal time

IdeallyIdeally• Monday has 8 hours• Each week has 40 hours• Monday has 8 hours• Each week has 40 hours

InsteadInsteadMonday has:• 3 hours of meetings• 1 hour of email• 4 hours left for project

Monday has:• 3 hours of meetings• 1 hour of email• 4 hours left for project

This developer will only make 4 hours of progress

on Monday

It will take two calendar days to complete one ideal

day of work

This developer will only make 4 hours of progress

on Monday

It will take two calendar days to complete one ideal

day of work

“How long will this take?”

Are you answering what is being asked?

“How long will this take?”

Are you answering what is being asked?


27

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Story Points

► The “bigness” of a task

► Influenced by: How hard it is How much of it there is

► Relative values are what is important A login screen is a 2 A search feature is an 8

► Points are unit-less

As a user, I want to be able to have some but not all items in my cart

gift wrapped


gift wrapped 55


28

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



More on Story Points

► Approach for starting the sizing process: Assign 1 to smallest story or Assign 5 to a “medium” story Size others by comparison/analogy Alternative: Small-Medium-Large-XL

► Benefits: Point sizes never decay Sizes don’t change based on estimator Are independent of the implementer Measure of size, not duration Encourage cross-functional behavior

► Shortcomings: Can be difficult to get started Must estimate initial velocity (but you can easily get it after 1 iteration)

Problem with T-Shirt SizingRelative relationship between sizes is lost. Example: How much bigger is a Large than a Medium?

Instructor Says:I recommend using Story Points. Most agile projects are using storypoints.

Instructor Says:I recommend using Story Points. Most agile projects are using storypoints.


29

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Point Sizing Units

► A 1-point and 2-point story are easily distinguishable The 2-point story will be twice the size of the 1-point story

► A 17 and 18 story are not very distinguishable What’s the difference between 17 and 18 anyways?

► Use units that make sense 1, 2, 3, 5, 8 1, 2, 4, 8 Include 0 and ½ if desired


30

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Exercise: Fruit Points

► Use “Fruit Points” to size the following breeds

watermelonorange

blueberrycranberrystrawberry

applegrapefruitbanana

pearpeach

watermelonorange

blueberrycranberrystrawberry

applegrapefruitbanana

pearpeach

Suggestion• Assign 1 to smallest story or Assign

5 to a “medium” story• Estimate size of others by

comparison/analogy


31

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Approaches to Sizing

► Estimates are made by a GROUP not an INDIVIDUAL

► Use a consistent relative scale

► Combine techniques Expert Opinion Analogy Disaggregation or Decomposition Planning Poker


32

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Estimate by Analogy

► Comparing an un-sized story to previously sized stories “This story is like Story 5, so it has the same number of points”

► Triangulate Compare the story to multiple previously sizes stories – not just one “This story is the same size as Story A and Story B. Both A and B are 5

points, so this story is also 5 points”

StoryA

StoryA

StoryB

StoryB

StoryE

StoryE

StoryC

StoryC

StoryD

StoryD

StoryF

StoryF

3pts

5pts

8pts


33

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Consider these two


34

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Disaggregation/Decomposition

► Breaking big stories into smaller stories

► Goal is to define stories that can fit into single iterations

► Don’t spend too much time A little effort helps a lot A lot of effort only helps only a little more

Effort

Acc

ura

cy

100

50

At some point, extra effort decomposing actually reduces accuracy (See Critical Chain Project Management reference)


35

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Planning Poker

► What is it? It is a tool to facilitate group sizing

► What do you need? Entire team – including product owner/customer Deck of planning poker cards with point sizes Stories


36

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Planning Poker – How to Play?

1. Each team member is given a deck of cards – each card has a point size written on it

2. Customer/Product-Owner reads a story► Customer must be knowledgeable enough to discuss each story

3. The story is briefly discussed, questions answered etc.► The discussion should be sufficient to determine the complexity and relative size of the work

4. Compare story to other, previously sized stories► Use analogy and triangulation techniques

5. Each team member secretly selects a card that is his or her estimate► Sizes should be presented together

6. Cards are presented to the group at the same time► Each person’s opinion is represented

7. Differences and outliers are discussed► Discuss why some people think a story is bigger than what other people think

8. Re-estimate until estimates converge► Sometimes the exercise needs to be time-boxed► Sometimes some negotiation is needed – “Meet the size half-way”

9. If 1 person is a holdout, but is very close Ask them if the consensus is agreeable


37

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Planning Poker – an example:


gift wrapped


gift wrapped

Round 1 Round 2

Jill 3 5

Bob 8 5

Yang 2 5

Ann 5 8

Todd 5 5

Result: Story Size = 5 Points


38

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Exercise: Remodeling my Kitchen

In groups: Size in “Kitchen Points” using planning poker the following stories:

► Install new hardwood floor

► Refinish (remove, sand, repaint) the cabinets

► Replace my tile countertop with granite

► Repaint entire kitchen

► Lay shelf paper

► Install recessed lighting

► Replace electric stove with gas stove

► Install a new oven

► Plumb the island and add sink


39

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Why Planning Poker Works?

► Emphasizes relative estimating

► Focuses most estimates with an approximate one order or magnitude

► Everyone’s opinion is heard

► Estimators are required to justify sizes

► It’s quick

► It’s fun


40

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Velocity – a quick reminder

► The rate of work completion

► The amount of sized work completed in an iteration

► The number of points per iteration


41

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Release Planning

Product Backlog

Release Planning MeetingRelease Planning Meeting

Iteration1

Iteration2

Iterations3-6

Release Plan


42

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Story C

Story G

Example (Velocity = 21 Points)

Story A

5Story B

3

Story D

8Story B

5

Iteration 1

Iteration 2

8

Story H

8

5

Iteration 3-6

Story E

5

Story I

2

Story J

1

Story L

13

Story F

13

Story M

8

Story P

5

Story Q

8

Story K

5

Story O

13

Story N

8

Story R

3


43

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Updating the Release Plan

► Revisit the release plan at the end of every iteration Agile planning is continuous and adaptive

► Update plan based on: Current understanding of velocity Current prioritization of backlog

► Should take little time – but highly effective


44

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Release Plan Updating Example

Story A 5

Story C 5

Story G 3

Story D 3

Story K 5

Story B 5

Story E 3

Story F 3

Story J 2

Story H 5

Story I 5

Story L 3

Initial Release Plan forecasted an iteration velocity of 16 points. The Release schedule allows for 3 iterations. At Velocity of 16, the forecasted story points to be delivered by the release is approximately 48.

During Iteration 1, on 13 points were completed. Therefore, the release plan can be updated to reflect the new velocity.

Ite

ratio

n 1

Ite

ratio

n 2

Ite

ratio

n 3

Story A 5

Story C 5

Story G 3

Story D 3

Story K 5

Story B 5

Story E 3

Story F 3

Story J 2

Story H 5

Story I 5

Story L 3It

era

tion

1It

era

tion

2It

era

tion

3

√√√

With a lower iteration velocity, fewer stories are now planned for – however, as these are prioritized lower on the backlog – they offer the least value


45

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



0

10

20

30

40

1 2 3 4 5 6 7 8 9

Iterations

Vel

oci

ty

Multiple views of Velocity

Last Iteration = 36

Mean = 36

Mean (worst 3) = 29

Worst = 25


46

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Extrapolate Release Scope from Velocity

At our slowest velocity we’ll finish here

At our current velocity we’ll finish here

At our long-term average velocity we’ll finish here


47

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



15

9

2022

8

13

19

14

0

10

20

30

1 2 3 4 5 6 7 8

Iterations

Velo

city

Here are the results of the last 8 iterations. There are 6 iterations left. Using this data, update the release plan by drawing 3 arrows into it

Running Total Points Story

5 5 Story A

10 5 Story G

23 13 Story D

31 8 Story K

51 20 Story B

59 8 Story E

64 5 Story F

72 8 Story J

77 5 Story H

85 8 Story I

90 5 Story L

93 3 Story M

Exercise: Update the Release Plan

Last Iteration =

Long-term average = 15

Mean of worst 3 =


48

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



A Final Notes on Story Points and Velocity

► Story points are specific to a team and product

► Points from one team’s backlog cannot be compared to another team’s backlog – comparing Apples to Oranges

► Velocity is dependent on points and therefore cannot be compared across teams

“If you want a guarantee, buy a toaster.” – Clint Eastwood in The Rookie

“If you want a guarantee, buy a toaster.” – Clint Eastwood in The Rookie


49

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Iteration Planning

Iteration

1


3


5

Iteration

2


5


1


2

Iteration

3


3


3


2

Product Backlog (Stories)

Define test cases 4

Code UI 8

Code middle tier 12


12

Automate tests 6


We are talking about these

right now


50

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



2 Approaches to Iteration Planning

► Commitment-driven iteration planning “How much are we, as a team, willing to commit to?”

► Velocity-driven iteration planning “We finished 20 story points last time, let’s plan on 15 story points this time”


51

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Commitment-driven Iteration Planning

► Discuss the highest priority item on the product backlog

► Decompose it into tasks

► Estimate each task (in hours)

► Ask: “Can we commit to this?” If yes, see if another backlog item can be added If not, remove this item but see if we can add another smaller one

► Shortcomings of Commitment-Driven Iteration Planning Cannot perform longer-term planning Risk of Parkinson’s Law


52

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Velocity-driven Iteration Planning

Adjust Priorities

Determine Target Velocity

Do in any sequence

Estimate Tasks(in hours)

IdentifyTasks

Select Stories

It is sometimes helpful to determine an objective for the iteration“At the end of the iteration I want to show…”

Do not try to have the total estimated hours equal to the iteration capacity.


53

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



Agile Planning Lifecycle Summary

Budget

Schedule

Scrum/Stand-up

Product Increment

Velocity


54

____ __ ____ _____ ____ ______ _____ _____ ____ _____ _____ _____ ____ _____



References

This presentation is based directly on the book “Agile Estimation and Planning” by Mike Cohn- this book is highly recommended for anyone who intends to do estimation and planning on agile projects.

Other References Used in this Deck:

► “Agile Estimation and Planning” – George Schlitz. Presentation Material

► “Agile Estimation and Planning” – Mike Cohn. Presentation/Training Material

► “Planning and Tracking on Agile Projects” – Mike Cohn. Presentation Material

► “Estimation Games” – Rob Thomsett. An article about common bad estimation games and antipatterns (http://www.thomsett.com.au/main/articles/hot/games.htm)

Documents

Materials Licensed from BigVisible Solutions Training Solutions Agile Planning v. 7.7.1