agile estimating and planning

Planningagile estimating & planning

your instructor

DerekNeighborsderek@integrumtech.com@dneighbors

The Purpose of planning

why plan?

Reduce RiskReduce UncertaintySupport Better Decision MakingEstablish TrustConvey Information

what Makes a good plan?

Sufficiently reliable for making decisions.

what makes planning agile?

Focused more on planning than the plan Encourages changes Results in plans that are easily changed Is spread throughout the project

Planning statistics

60% of projects significantly over run their cost estimates

64% of features features included in products are rarely or never used

The average project exceeds it’s estimate by 100%

planning by activity instead of feature

Activities don’t finish early

Lateness is passed down the schedule Activities are not independent

Parkinson’s Law states “Work expands so as to fill the time available for its completion”

additional traps we fall into

Multitasking causes further delays Features are not developed by priority We ignore uncertainty

Integrum Tip:Don’t split people among multiple projects.

Small iterations combat uncertainty.

the manifesto says...

Individuals and Interactions over Process and Tools Working Software over Comprehensive Documentation Customer Collaboration over Contract Negotiation Responding to Change over Following a Plan

an agile approach

Work as one team Work in short iterations Deliver something each iteration Focus on business priorities Inspect and adapt

multiple levels of planning

release planning

GenerateUser

Stories

Estimate User Stories

Select IterationLength

EstimateVelocity

PrioritizeUser

Stories

SelectStories

Release Date

Define Conditions

ofSatisfaction

Conditions of satisfaction

What is success? Date driven? Feature driven?

estimating size

DesiredFeatures Estimate

SizeDerive

Duration Schedule

Story Points

estimate stories

Estimate gets to cost and time Not necessary to estimate everything always

estimates are Not commitments

An estimate is a probability Commitment can’t be made on probability Commitments are made to dates Estimates are not implicit commitments

estimates are shared

Not done by “expert” individual We don’t know WHO will do the work Those not doing the work still have the

ability to call bullshit

estimation scales

1, 2, 3, 5, 8 and 13

1, 2, 4, 8 and 16

Fibonacci reflects the proportional uncertainty to estimate the further from the smallest you are.

Still reflects non-linear pattern that highlights great uncertainty the further you get from the smallest.

story points are relative

10

1

example

Labrador - 5 Terrier - 3 Great Dane - 10 Toy Poodle - 1 German Shepard - 8 Bulldog - ???

estimating in ideal days

15 min qtr x 4 = 60 minutes

Average Length of Football Game?

estimating size

5 Hours?6 Wheel Barrows?

deriving an estimate

Expert Opinion Analogy Disaggregation

planning poker

Combines all three methods Quick but reliable Right amount of discussion (< 2 min) Smaller sessions Before project starts and within project

Workshop #1

In teams of 3 to 4 estimate (size) the following water vessels: row boat, canoe, speed boat, freight liner, cruise ship, yacht, sail boat using planning poker.

20mActivity Time

probability distribution

epics & Themes

Blocks of Epics/Themes Bigger numbers with same non-linear seq More uncertainty More likely estimates inaccurate

Why ideal days?

Easier to explain outside team Easier to estimate at first (?)

Why story points?

Help drive cross-functional behavior Do not decay Pure measure of size Typically faster to obtain estimate My ideal day is not your ideal day

law of diminishing returns

when not to re-estimate

Relativity is right, velocity wrong. Adjust velocity. Recalculate release.

when to re-estimate

Relativity is wrong ex: API difficult to work with Adjust stories with API work

re-estimate partially completed stories

No such thing as partially completed! Should only happen if so bad can’t be

completed in next 2 iterations Probably better to decompose and

estimate decomposed stories

select iteration length

Shorter times tightens feedback loops Shorter times can feel like more overhead Longer times can be more comforting

derive duration

DesiredFeatures Estimate

SizeDerive

Duration Schedule

Velocity

estimate velocity

Yesterday’s weather Sample week, averages Sample sprint

velocity corrects estimation errors

How Long to Paint?

What Size Rooms?

10’ x 12’

20’ x 24’

prioritize stories

Too little time, too many features Helps with decision making Helps reduce churn

factors in prioritization

The financial VALUE of having The COST of developing/supporting The amount/significance of NEW

KNOWLEDGE The amount of RISK removed

value

Can be financial Can be desirability

Cost

Cost can change depending on when Can convert points to money

new knowledge

High

High

Low

Low

Means Uncertainty(How)

End

Unc

erta

inty

(Wha

t)

High

LowMeans Uncertainty

(How)

End

Unc

erta

inty

(Wha

t)

High Low

Risk

High

High

Low

Low

Value

Ris

k

High

LowValue

Ris

kHighLow

High riskLow value

High riskHigh value

Low riskLow value

Low riskHigh value

Avoid Do first

Do SecondDo Last

financial value

Net Present Value Internal Rate of Return Payback Period Discounted Payback Period

theme return

revenue sources

New (Customer / Markets) Incremental (New from Existing) Retained (Prevent Customers Leaving) Operation Efficiencies

Calculating new revenue

calculating incremental revenue

calculating retained revenue

calculating operational effeciencies

estimating development costs

putting it all together

net present value

internal rate of return

payback period

discounted payback

comparing returns

prioritizing desirability

Must Haves:a beda bathrooma deskclean

The More, the Better:comfort of the bedsize of roomvariety of equip in fitness room

Exciting:built-in TV’s on treadmillsfree bottled water in roomfree hi-speed internet

Hotel Features

kano model

Threshold, or must-have, features Linear features Exciters and delighters

kano customer

Low

HighC

usto

mer

Sat

isfa

ctio

n

Abs

ent

Fully

Impl

emen

ted

Feature Presence

Perfo

rman

ce / l

inear

Must-have, Mandatory

Exciters anddelighters

kano assessment

categorize responses

distribution of results

relative weighting

Workshop #2

In teams of 3 to 4 prioritize the provided backlog using by value, cost, new knowledge, risk removed and desirability utilizing the methods show today.

45mActivity Time

select stories and date

Feature driven.. Stories determines date Date driven.. Date determines features Can be detailed by iteration Can be vague by iteration

release planning

Helps product owner and whole team decide how long until release of product Conveys expectations about what will be

developed Serves as a guidepost towards progress

extrapolating a plan using velocity

when to split a story

Too large to fit in an iteration Won’t fit in an iteration Story is Epic (needs better estimate)

splitting across data

Split stories along the boundaries of the data supported by the story Split exceptions or error conditions

split on operational

Split large stories based on operations that are performed within the story ex: search Split large stories into separate operations

(ex: CRUD)

remove cross-cutting concerns

Remove from security, error handling, logging, etc

don’t meet performance constraints

Consider splitting a large story by separating the functional and non functional aspects into separate stories. “Make it work. Then make it work faster.”

mixed priorities

Separate a large story into smaller stories if the smaller stories hae different priorities.

don’t split into tasks

Don’t split a large story into tasks. ex: Not UI, Model, Controller, View Story Use tracer bullets

avoid temptation of related changes

Don’t add related changes Unless related changes equivalent priority “While I’m in that code...” Only makes it worse

combining stories

It’s okay to combine smaller stories Use caution and keep things managable

Workshop #2

In teams of 3 to 4 create a release plan using velocity.

20mActivity Time

release burndown charts

release planning vs sprint planning

Use different scales (points / hours) Use commitment driven approach