Lead Time is the average time from when client submits a request till related software is produced. Cycle Time is average time between two successive releases from the system. The lower the Lead Time the higher the Throughput, which is number of client-valued features, released every time interval. Ultimately this impacts the bottom line by having lower cost per feature.
In an earlier post here, I talked about how sizing can ultimately adversely impact team productivity. In this post, I am suggesting that estimation elongates the Lead Time as well and that it is non-value add. I based my proposition based on first-hand involvement with software product vendors. For me, estimation at best is a way for protective risk avert business and doesn’t allow break-through results.
Estimation requires engineers to be involved in the presales cycle, which consumes the capacity of the engineering organization. Before approving the development request, there are many hours spent to vet this request. Allocation of those hours requires coordination and scheduling which further elongates the Lead Time.
A feature does not take longer duration because of its size, instead because of the inherent risks. Risks can be identified during the detailed planning for implementing the feature by the developers.
Estimation is tricky and can change according to requirements change. Therefore, regardless of whatever the estimation, it will likely change.
Less capable to address requirement churn
During the interval of doing estimation in the presales cycle, requirements will most probably be changed. This can lead to new unidentified risks.
Client bequests “waiting” for engineers to estimate is a waste. Engineers have to “task switch” from their development work to presales creating another waste. Involvement of engineers in presales adds “extra process” and formality to the work.
Elongating the Lead Time is a symptom of protective relationship between the vendor and the client. This is because the vendor wants to ensure completeness of all due diligence before being embarked to the client request.
What should we do then?
- Create measurement database of Lead Time, without the time required for the approval process.
- As we receive a new request, use this database to figure the probable time it can take.
- Identify risks related to this request. Add 15%, 25% or 45% to the previous estimate based on whether risk level is low, medium or high.
- Communicate the estimate to the client in 24 hours.
- Implement client request as fast as possible, retrospect, and update the measurement database.
Cycle Efficiency: It is the percentage of time we actually spend doing value-add work on the client request compared to the overall Lead Time. It’s not unusual to find this percentage less than 5%. Mature organizations can reach 50%, which is an order magnitude improvement.