Summary

Advanced planning techniques that deliver on promise of empirical evidence based predictability and improve organizational Agility.

Learning Objectives

• Overview of various Estimation biases
• Estimates anchor benefits - Or Why estimates make me frown?
• Learn about narrowly bound contexts where story points based estimation is effective, or When not to use story points.
• How to cope with Story points
• Empirically gathered cycle-time measurements to make release level date & scope decisions and manage dependencies
• First and Second law of dependency management

• Content rating (0-no new ideas, 5 - a new ideas/approach, 9-new ideas): 7
• Style rating (0-average presentstion, 5 - my level, 9-I learned something about presenting): 4

It's still a guess

Two approaches Expert judgement based Statistical based

Human biases in expert judgement Statistics have problem when situation changes

Saying we don't know is not accepted Making up bullshit answer is accepted Why - to get people off our back

Estimate what we know we know But now that we don't know

Daniel Kaneman

Successive estimates get more optimistic

When people are asked to break down work in detail and become even more optimistic

Confidence estimators have in own estimates is unjustifiable high

Anchors Don't think about a camel

Competence Your estimate implicates you. Is a measure of your competence on team

Irrelevant details. Read story then talk about crap

Temporal distance In 3 months you will have to write your name on a white index card in a blue fountain pen

Closer, mind switches to view of impediments

Relative size estimation has problems Directional bias Real relative sizes

Memory of past incorrect and so cannot be used forward

Anchoring effect Expected zone of

Martin Fowler - quote

Expectation from planning See list No estimation

Implication of story point is that you can go from concept to cash Devops

If you are not in this place then you might want to use something else.

Alternative count stories / sprint Steve Rogalsky - measured for a year counts vs story

Change from points to counts Split story - until valuable and doable

We have weak definition of done If we have stabilizing sprints, then rest are de-stabilization sprints

Wrestling with unknown unknown work

Every source off delay between development and go live has whiplash effect

Best way to reduce uncertainty, is shorten time horizon Say 2 months

Get empirical data How many in stories in stabilizing and destabilization sprints

Dependency management Laws Don't create dependencies Only schedule dependency when you know team can take it on and you know how long on average the team will take to do it.

Program level metrics Idea - Dependency board Team vs epics Shows most involved team, highest risk epic

Dinner at 7 principle If 10 people What time do you tell them to turn up

Make visible on board Influence what you plan for in next sprint PO / sm source

Reduce time of delay - has more effect on release on than productivity of team Focus on this Cumulative flow diagram

Actively manage delay Prioritize epics

Queue size - how many items are waiting because of dependencies Don't let them accumulate Set explicit limits

Team has 'if you have a dependency on us, max 2, you put them on this queue'