How I started believing in Cycle Time over Estimation
1–10 of 36 posts
Re: How I started believing in Cycle Time over Estimation
#2I 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?
Re: How I started believing in Cycle Time over Estimation
#3I 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 think the type of estimation meant here is the agile type, where the team looks at a feature/requirement and estimates the time or relative effort based on the nature of the requirement + whatever other factors they choose. It's usually more intuitive and not based on historical data.
Re: How I started believing in Cycle Time over Estimation
#4I am still not clear at all how "cycle time" is a meaningful measure without correcting for size of the feature.
I'm also confused as to how you can look at "mean of one week, with a standard deviation of two weeks" and not wonder about the asymmetry of the distribution, and if mean/sd are really the metrics of choice here. (I'd think 1st/3rd quartile are a better choice, because it gives some clue as to skewedness)
Re: How I started believing in Cycle Time over Estimation
#5I 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?
he also links to a conference talk about this. "you can make a claim that estimates are based on past behavior, but the fact is that what you're implementing is something that hasn't been implemented before. So any kind of measurement that you've made of something that has happened in the past is not going to impact what you're doing now" https://www.youtube.com/watch?v=QVBlnCTu9Ms
Re: How I started believing in Cycle Time over Estimation
#6We had a much more primitive version of this for our product roadmap. After working with mostly the same dev team for a few years, we felt that in a given year we seem to consistently be able to complete X “big” projects, Y “mediums” and Z “smalls” despite all the random stuff that invariably pops up.
So that list was the spine of our annual planning, the stuff that we really prioritized. The rest of the stuff that people wanted to do would have to fall in between the gaps of that master set.
It worked surprisingly well for us, but we had to build this group experience first. After a few years with another dev team at another company, I brought it up as an alternative to over ambitious roadmaps and it worked well there too.
How much of this was just due to more team familiarity and experience or this oversimplified process? Don’t know. But it felt like the roadmap trade offs were more thoughtful, devs felt more relaxed and had reserves if we had to red line a bit, and fewer missed commitments.
Re: How I started believing in Cycle Time over Estimation
#7I am still not clear at all how "cycle time" is a meaningful measure without correcting for size of the feature. I'm also confused as to how you can look at "mean of one week, with a standard deviation of two weeks" and not wonder about the asymmetry of the distribution, and if mean/sd are really the metrics of choice here. (I'd think 1st/3rd quartile are a better choice, because it gives some clue as to skewedness)
I'd say SD is a much better measure here, precisely because that big standard deviation jumps out at you. My guess would be that the 3rd quartile is some sensible-sounding number like 1.2 weeks but there are some huge outliers pulling up the SD.
Re: How I started believing in Cycle Time over Estimation
#8The 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 confusion from the look of my team lead. How could I say it would take over five days for a change that we estimate to take 10 minutes!
Isn't this like comparing apples and oranges? The estimation of 10 minutes is clearly "the time it takes to flip the flag", but what they actually want to estimate is "the time it takes to make it into production in a safe manner".
Maybe the team leader is confused because they thought this was a man-hour estimation? And they're now afraid that one developer will work full-time five days on it?
> On Monday, we started with the stand-up and discussed picking up this task. Another engineer proposed fixing a bug on another component first before turning on the flag.
Doesn't this imply that their 10 minute estimation was done completely without asking the team?
> As humans, it is impossible to consider all the potential complexity. […] We did not consider a legacy system with bugs and scaling problems. […] We did not consider a combined release process with a Release Manager.
Really? You couldn't consider the complexity of a release process you designed yourself? You honestly thought this was a 10 minute task even though you knew you were dealing with a legacy system?
Re: How I started believing in Cycle Time over Estimation
#9I am still not clear at all how "cycle time" is a meaningful measure without correcting for size of the feature. I'm also confused as to how you can look at "mean of one week, with a standard deviation of two weeks" and not wonder about the asymmetry of the distribution, and if mean/sd are really the metrics of choice here. (I'd think 1st/3rd quartile are a better choice, because it gives some clue as to skewedness)
I'm guessing it's a good metric here because most of their tasks are small tasks that only takes a few hours to complete (in code) and then the average Cycle Time becomes the average overhead for getting a fix into production.
Re: How I started believing in Cycle Time over Estimation
#10I 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?
he also links to a conference talk about this. "you can make a claim that estimates are based on past behavior, but the fact is that what you're implementing is something that hasn't been implemented before. So any kind of measurement that you've made of something that has happened in the past is not going to impact what you're doing now" https://www.youtube.com/watch?v=QVBlnCTu9Ms
I'm rather skeptical on this idea that just because a specific feature was never implemented, or just because a specific bug was never fixed, that estimates based on past behavior don't work. That assertion doesn't have any basis on reality. I mean, implementing a feature of fixing a bug is not an isolated event performed with improvised approaches starting from scratch. Teams have processes and procedures that are standardized and take time, and need to be performed sequentially, which means that the improvisation part at best represents a small subset of the time invested working on a ticket.
For a concrete example, let's imagine a team which has a continuous delivery pipeline which involves a code review step and manual acceptance tests. Let's say that the code review can stay in a queue for a couple of hours, or even sleep into the next day, and that the manual acceptance tests require the feature to be deployed to a preprod stage after passing through all unit and integration tests, and that it might take a day to run.
With this process alone, the ticket already takes at least 2 or 3 days between being assigned to someone and being marked as done.
Now, let's say that the coding bit of a random ticket might take 5 minutes or 3 days. This means that the overall time between the start and end time of a ticket is about 4 days +- 2day, which means worse case scenario, it takes 6 days to close a ticket.
How is this sort of estimate not possible?
The problem of providing estimates is not one of predicting the amount of time it takes to close a ticket. The problem of providing estimates is a problem of processes, and how to adequately organize, structure, and classify work. If you don't know what you're doing then you don't know when you're done.