How I started believing in Cycle Time over Estimation
The gist of this article is good. Fixing the code is often the smallest part of rolling out a bug fix. That&#x27;s extremely important to be aware of. Using historical data can be a great way of seeing how fast you can <i>actually</i> roll out changes.<p>But I don&#x27;t get how they went from that to &quot;estimations are bad&quot;. It seems to me that they&#x27;re just doing better estimations now by looking at historical data?<p>&gt; 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!<p>Isn&#x27;t this like comparing apples and oranges? The estimation of 10 minutes is clearly &quot;the time it takes to flip the flag&quot;, but what they actually want to estimate is &quot;the time it takes to make it into production in a safe manner&quot;.<p>Maybe the team leader is confused because they thought this was a man-hour estimation? And they&#x27;re now afraid that one developer will work full-time five days on it?<p>&gt; 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.<p>Doesn&#x27;t this imply that their 10 minute estimation was done completely without asking the team?<p>&gt; 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.<p>Really? You couldn&#x27;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?