How I started believing in Cycle Time over Estimation

And thanks for replying!

> It is correct that is can still be seen as migrating to a better form of estimation.

Well, from my perspective there is still estimation going here: A project manager came to you asking for a timeline for a feature and you replied with a concrete number of days. I don't think it makes any difference to the project manager whether you call it an "estimate" or "prediction".

> For me personally, I went from estimations are just really poor even for the most simple things and not worth the effort.

The example you're presenting isn't showing this because it doesn't seem like you made any actual effort estimating it. It would have been better if you showed that you spent hours talking with various people for input and then in the end the Cycle Lead was more precise. In this example you did an estimate without even talking to the team! (Yes, you talked to the team leader, but apparently they didn't know that there was performance issues with enabling the flag so there's some communication lacking here.)

If you wanted to properly estimate it you would at least (1) ask in the stand-up if there was any concerns about flipping the flag and (2) communicate with the release manager to see that it would have been possible to do a release. And it looks like if you actually did this then you would end up with an estimate that is closer to the actual time. It might also have uncovered that there was another release process happening at the same time.

Considering that the standard deviation is two weeks (!) it seems more that you were lucky in this example that there wasn't more unplanned work. What if the performance issue required three days of work instead of one? What if the release manager told you that they were upgrading database servers and couldn't do a release for two days?

> Yes, it was done with just the team lead and me. We migrated away from Scrum at that point and we did not do full team refinement with estimations sessions pre-sprint.

There's a middle way between "full team refinement with estimation" and "only team leader and me estimates". You can ask around and double check before giving out estimates to project managers.

> But I don't get how they went from that to "estimations are bad".

If "estimations" means the usual, i.e. asking "Ok everyone, how long do you think this task will take to complete?" then yes, that is largely a waste of everyone's time. Those estimations are bad.

> they're just doing better estimations now by looking at historical data

Yes, better estimates are coming from data. The people aren't "doing estimation" any more, it's being automatically calculated. Doing estimation takes time and give wildly wrong results.

I couldn't read all the text, but I believe the metapoint is that the need for accurate estimates drop as the cycle time is reduced.

It is all about feedback.

My analogy is an old analog style joystick that positions a simulated robot arm on a screen. If the update rate is high enough I can track a rapidly moving dot, but if it drops across some threshold, and I needed to accurately position the arm at some time in the future, then I would need to construct a huge model of the system, know the force, stiction, friction, mass, moment and thermal expansion. (edit, I have another analogy, anyone can spray a moving target with a hose, but using a bow and arrow requires skill and practice)

Feedback allows us to use unpredictable components to make predictable systems. Those systems are nearly always amplifiers. Systems that use direct feedback don't have to have the same reductionist model as something that needs better prediction (estimates).

This is why Lisp was a super power in the 80s, it had a repl. Same as Smalltalk, the IDE and repl and the universe were all the same thing. It makes total sense that agile came out of a system based around repls and instant feedback. Arduino did it for embedded dev. Hypercard for programming, the spreadsheet before that.

Highbandwidth feedback allows us to be less skilled. Good estimators need to be highly skilled to make those estimates. Hose vs arrow. That reminds me, have you seen a really skilled FPS player on a predictable but high ping connection? They are almost timeless in how they predict the future, and to everyone else they dance between every 10th frame. Amazing predictors!

You can't agile a martian probe (yet). As new ways are discovered to reduce cycle times, the time between cause and effect, each proceeding structure of feedback is replaced with an even higher bandwidth one. Robust DFU is a metarepl as hardware manufactures race to ship products that are literally not finished and require a firmware update on boot to even function.

What works well for me:

1. Split the project into tasks. (a task taking at least 3-5 PTs)

2. Have a POC / prerelease phase

3. For complex tasks introduce a second polishing task, like "Basic User management 1/2" and later "Basic User management 2/2". If the second one isn't needed: Great!

4. For all tasks/areas estimate a lower and an upper estimation in hours or PT.

5. Revisit your estimation afterwards using this process:

5.1. Imagined that someones gives you the following choice: You get 1000$ if your the true value lies within your estimation 90% of the time. Or you can roll a dice and in 9/10 you get the 1000$.

5.2 If confidently pick your estimation ("I'm 100% sure the true value is within my bounds") then it's too wide.

5.3 If you rather pick the dice-roll, then you don't trust your estimation, it's too narrow.

5.4 Adjust your estimation until both options seem equally probable to you: dice-roll or your estimate being true 90% of the time.

The benefits described here are achieved by ANY abstracted estimation system. Ask people to estimate in units of difficulty, complexity, cups of coffee, whatever. Keep those units consistent relative to each other (a 4 cup task looks roughly twice as big as a 2 cup task, in advance). Track the relationship between units and hour/days over several sprints, and your average automatically factors in all the external things like team collisions, illness, developer downtime, refactoring, bugfixes, release process, etc. The research shows that the law of large numbers makes this MUCH more accurate than pure time estimation. (time estimation is extremely difficult to get correct more than about 35% of the time; averages of consistent units are correct enough to run a casino budget).

The scrum people will tell you to call this unit "story points", but it doesn't matter what you call it, as long as it's based on something connected to task duration. Difficulty, complexity, risk, whatever.

Note that if you're tracking the conversion rate between developer estimated hours and real hours, you're already doing this. But you'll get an increased accuracy by using units that are explicitly not time-related, just because of quirks in how human brains think about time.