Sounds more like a case for using cycle time as a checksum to make sure the team’s estimates are fully considered.
They’re clearly missing 4 days of standard requirements in their estimates.
How I started believing in Cycle Time over Estimation
11–20 of 36 posts
Re: How I started believing in Cycle Time over Estimation
#12Earlier quoted context omitted.
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 s…
Yeah, I think the problem the OP overlooked is that most of the cycle time was taken by various internal company processes and these are really not novel every time therefore it takes a similar amount of time to deliver different features. This in my mind is simply called estimation.
Re: How I started believing in Cycle Time over Estimation
#13[deleted]
Re: How I started believing in Cycle Time over Estimation
#14The 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…
The distinction between effort (man hours) and lead time gets lost often. Clueless managers ask for the first and take it for later.
Re: How I started believing in Cycle Time over Estimation
#15I am the author of the story. I appreciate any feedback so that I learn from you! I will be participating in the discussion.
Re: How I started believing in Cycle Time over Estimation
#16The 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…
Thank you for your comment!
> 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?
For me personally, I went from estimations are just really poor even for the most simple things and not worth the effort.
It is correct that is can still be seen as migrating to a better form of estimation. If you look at the conference talk by Allen Holub[1]. He tries to make the distinction between estimation and prediction is that the latter is only data driven.
> 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?
That could be the case. I never looked at it that way.
> Doesn't this imply that their 10 minute estimation was done completely without asking the team?
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. We would collaborate on the technical solution for any story when we would pick it. This could be full team to two engineers. The engineer that brought up the bug would probably bring up the bug.
> 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?
Yes, I honestly did! It was just a simple code change in our terraform code to set the config from false to true and cycle the machines. I should clarify this more in the story.
Re: How I started believing in Cycle Time over Estimation
#17I 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?
Thank you for your question!
Yes, I try to make the distinction between prediction looking at historical data and estimation asking the engineers how long it will take.
Re: How I started believing in Cycle Time over Estimation
#18Earlier quoted context omitted.
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 s…
Good point you hardly ever start with a clean slate. Using historical data or asking engineers to estimate how long it will take will always be based upon this past performance.
But the point I try to make is that it is hard to take into account all the factors you have to deal with in a complex situation. As a human, you tend to ignore irregular influences. With tracking tools, you get this data right out of the box and it is more accurate in my opinion.
Re: How I started believing in Cycle Time over Estimation
#19I 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.
I agree that the Standard Deviation is a good measurement because of the big outliers.
We also focus on these during retro. What made us remarkably slow? You want to drive down these issues.
This investigation can help you in future work. I worked with another team that was consistently slow if they would need to build new pipelines or get connections up and running to third parties(heavy regulated environment). This insight helped us in planning.
Re: How I started believing in Cycle Time over Estimation
#20The 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…
This is why definition of done is quite important, to get everyone one the same page about what it means to complete a task.