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!

  1. Have each developer grade every* tasks on two factors: Difficulty and Certainity Use a bell curve based 1-3, or 1-5.
  2. Automatically track the "real time" it takes to complete each task (weekends, sick days, PRs, deployment delays, etc.)
  3. Update each developer's hidden coefficient based on new data.
    1. 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.
  4. 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.
  5. 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.

Made with Slides.com