Table of Contents
Dhaval Panchal - Estimating Is Not Planning
Advanced planning techniques that deliver on promise of empirical evidence based predictability and improve organizational Agility.
- 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
Action / Learning
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
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'