Diachronic Agility
Historical and Evidence based task estimation
Issues with Story Points
- Becomes a Time measurement with extra steps
- Developer-agnostic, 3 points is the same for each dev.
- Time estimates only improve through individual developer reflection and effort
- They need to learn how to translate difficulty and confidence into a story point measurement that is agnostic for the whole team, even as they bring on new developers.
- Type of work, or uncertainity about work must be implicitly factored in
- Bidding war between devs/PMs
- "Is it _really_ a 5? If it's a 3, we can squeeze in this other task..."
Why does this happen?
- Velocity per sprint changes
- New developers
- More/less familiar work
- Vacations/sick days
People are bad at time estimating
- Competing objectives
- PMs want features
- Devs want good code
Planning Fallacy
Daniel Kahneman
- Studied "Why are we always late?"
- Won a Nobel prize in Econ for this work
Self-enhancement
Optimistic predictions are satisfying and that it feels good to think that positive events will happen.
Self-presentation
People are motivated to present themselves towards others in a good light.
Personal vs. perceived control
People tend to be more optimistically biased when they believe they have more control over events than others.
How to Fix?
- People are bad at time estimating
- better at difficulty and uncertainty estimation
- People are consistent at how bad they are at estimation
Hide it!
- Have each developer grade every* tasks on two factors: Difficulty and Certainity Use a bell curve based 1-3, or 1-5.
- Automatically track the "real time" it takes to complete each task (weekends, sick days, PRs, deployment delays, etc.)
- Update each developer's hidden coefficient based on new data.
- Eg. Susan thought this task would take 3 days, with her coefficient the system guesses 4.2, but in reality it took 5. Behind the scenes her coefficient gets bumped slightly up.
- PMs and Leads use the hidden coefficient to generate accurate timelines with delivery ranges. Eg. each task becomes a probability distribution instead of a static timeline.
- Uncertainty is used for the "fuzziness" in timeline estimates and how much should the coefficient be modified (think Chess ratings)
Normal
Difficult
Trivial
Normal
Uncertain
Certain
Most tasks should fall within the 'Normal' ranges.
Follow a rough bell curve
More Insights
- Extreme discrepancies become an indicator for a retrospective.
- Shifting around tickets to different devs can automatically update timelines
- Tickets linked to PRs allow introspection on the code base
- Are their areas in the codebase that are very uncertain?
This is still a WIP
sorry.
Diachronic Agility
By Scott Tolksdorf
Diachronic Agility
Historical and Evidence based task estimation
