Definition

A feature is a work product that fulfills one more more stakeholder needs. Cycle time for a Feature is the average time from when an Feature first starts to be worked on to when it is fully tested and ready to be delivered (but not necessarily delivered).  

Once the Feature is created, it goes through approval and becomes implemented:

1. New: Stakeholder sees a business need and submits a request to have that need fulfilled.  
2. Exploring: The organization takes the request from the business release queue.
3. Defined: Detailed requirements and estimates have been gathered.
4. Planned: The development teams approve the feature's requirements.
5. Accepted:  All teams that need to do work related to the feature have agreed to implement the feature in the current release. 
6. Implementing: Developers and testers work on validating results and testing begins.  This is the start date of the cycle time.   
7. Ready for Delivery: The first attempt to deliver the feature.  This is the end date of the cycle time.
8. Delivered: All application versions of the feature are delivered into production.

The overall cycle time can be calculated by finding the difference betwen the start date and end date.

Feature Cycle Time = End Date - Start Date

The Feature Cycle Time is the total of the process times, during which the feature is worked on bringing it closer to delivery, and the queue times, during which a feature could be waiting in a queue, between the start and end dates. Queues can inadvertently increase the cycle time.

Cycle time can be measured in seconds, minutes, hours, or days.

Delays

The cycle time may include delays to the Feature, increasing both the process time and queue time. If many features are deferred to a future release, there may be a problem with the length of the queue.  To resolve this issue, you can:

• Count only the median cycle time, which effectively discards the features with high and low cycle times.
• Measure how long it takes to deliver 80 or 90% of features (which also discards the high cycle times).

If there are not too many deferred features, this can work.

It may be interesting to and look the metric when "deferred" features are excluded from the measure's calculations, or if you count only "high priority" feature requests.

If a Feature is sitting idle after leaving the Dev queue as a result of a dependency on two other Features that have not left the Ops and Test queues, then the development process could be slowed down. The diagram below shows how you can use  Virtualized Services to solve this issue.  The Features stuck in their queue are virtualized in order to avoid a long cycle time.

 

Once a Feature has left its queue in the Implementing stage, you can use  Automated Deployment to set up the testing environment earlier, thereby reducing the work time to implement and test the Feature, which also reduces the cycle time.

Conclusion

Because the cycle time is not measured until a feature is ready to be delivered, it may be a slow indicator of performance.  If you would like more frequent releases with business requests moving quickly through the lifecycle, adopting lean practices in order to detect bottlenecks and inefficiencies can provide opportunities for improving the cycle time. Controlling the queue (or batch) size is one lean approach to consider (see  DevOps Principles).