Advanced planning techniques that deliver on promise of empirical evidence based predictability and improve organizational Agility.
Two things are certain about estimates:
Estimates are always wrong
You will spend more time estimating that you should have otherwise used to do the work instead.
Agile Manifesto Values and Principles do not, not even once, mention “estimates” any where. Yet rapid adoption of estimation techniques labeled as “Agile Estimation” techniques puzzle me. In my experience as practitioner, advisor and coach : I have experienced very limited benefits from estimating and often find that estimates create more harm than good. There are however legitimate business concerns that need active management. Estimates hinder real business agility by servicing temporary comfort through plausible but highly improbable plans.
Following is outline of my talk:
Opening and Introduction
So you think you can estimate: Overview of estimating biases with references to current research in software context.
Impact of irrelevant and misleading information
Temporal distance : The further out in future you estimate the more optimistic your estimate
Relative Size estimation is prone to Directional bias and Assimilation Effect
Sequence reference bias: Biases introduced depending on number sequence used for story pointing
Recollection bias (flawed memory)
Exposure to biases is unavoidably high and there is no escaping it.
Estimates anchor benefits - Why estimates make me frown?
Applicability of Story point estimates.
Story points are applicable only in fully cross-functional teams that can move a request from Business to Production all by itself. Or in Scaled contexts where teams are fully cross-functional feature teams. In all other cases story points are inapplicable.
In applicability in scaled context with many dependent teams
Introduction to cycle time
How to gather empirical evidence in non-ideal contexts? - Single team
What happens in multi-team environment where teams are cannot be fully cross-functional and have shared dependencies?
I will share principles via case-study where I used cycle time measurements and dependency management board to actively develop empirical cycle time evidence to track a major Game release.
Note: This 45 minute talk is fast paced and assumes that participants are sound on their fundamentals.