In my experience, you need both numbers. A customer naturally wants to know when a change arrives in production. I call this "latency", you call it cycle time, but maybe there is a small difference because I also try to include the time it takes to even start development. But a customer also wants to know about effort, often. Because usually effort is what gets billed. So a 10min (realistically, the bill we be about…
How I started believing in Cycle Time over Estimation
31–36 of 36 posts
Re: How I started believing in Cycle Time over Estimation
#32The gist of this article is good. Fixing the code is often the smallest part of rolling out a bug fix. That's extremely important to be aware of. Using historical data can be a great way of seeing how fast you can actually roll out changes. But I don't get how they went from that to "estimations are bad". It seems to me that they're just doing better estimations now by looking at historical data? > I could tell confu…
Fwiw, there are some pretty prominent authors that suggest you are better off just counting the number of tasks in the queue and tracking the average time per task, rather than estimating at all. It’s just as reliable since everything averages out over time and the queue size is a leading indicator while cycle time is a trailing indicator.
Re: How I started believing in Cycle Time over Estimation
#33I feel like I'm fulfilling a stereotyped HN commenter role by asking this, but isn't "prediction based on historical data" actually, you know, an estimate?
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 t…
Re: How I started believing in Cycle Time over Estimation
#34Measure velocity for sure. Keep track of what kinds of things harm or improve it. But the absolute worst thing you can do is find an abstraction like tshirt size or rolling average and superimpose it on discreet work. You’re going to be wrong. And probably disappointed or disappoint someone else.
My strategy for estimation is:
- It’s tiny and I’m doing it now, I can give you an estimate within an hour margin.
- It’s small, it’ll be done in a reasonable amount of time that no further estimation is required.
- It’s not small and more research/design/planning is required. Any estimate you extrapolate from this is dishonest.
That’s it.
Edit: that wasn’t quite all. “It’s tiny” is reserved for urgent situations that require rapid response and not something I offer outside that situation. For daily work, it’s small or it’s too big to say. Tiny things are too easy to abuse (by managers or engineers) if they’re part of the normal flow.
Re: How I started believing in Cycle Time over Estimation
#35Earlier quoted context omitted.
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 t…
I just wanted to reply to say this was a great explanation and that I broadly agree.
Quip aside, I also learned a lot writing it. Always bet on the Scientific Method and if we know something works, we should have to justify not using it.
Re: How I started believing in Cycle Time over Estimation
#36Earlier quoted context omitted.
I just wanted to reply to say this was a great explanation and that I broadly agree.
Thanks for the feedback. Quip aside, I also learned a lot writing it. Always bet on the Scientific Method and if we know something works, we should have to justify not using it.
I went on a tour of Blue Origin, I learned next to nothing. It looked like a the rich kids house that had a coleco and a neo geo.
The picture they paint of spacex is one of being in continuous flow vs cautious pessimism.