Cycle Time Shows How Long Work Takes
You might wonder if your estimates are correct. Or you might wonder why some story is taking forever to finish. In that case, measure cycle time. In software, we have at least two ways to measure the time something takes: cycle time and lead time.
- Cycle time
-
The duration of time from when you put a card in the first in-progress column until when you mark the card as “done.” Cycle time measures the time the team works on the story.
- Lead time
-
The duration of time from when a card goes onto the backlog until you release the feature to the customer. Lead time is the entire time from backlog to customer use. If you have a staging area before you can move your product to production, your lead time is at least the team time plus that time.
The top figure illustrates the difference between cycle time and lead time. Here’s what happened when one team measured its cycle time as feedback for its estimates. The team added one piece of data: the day and time the card moved from one column to the next as it progressed through the flow.
The team then added the times T0, T1, T2, and T3 together to see the entire cycle time, as shown in the bottom figure.
The team collected data for one iteration and discovered this:
| Story | Duration |
|---|---|
Story 1 | 1 day |
Story 2 | 2 days |
Story 3 | 3 days |
Story 4 | 3 days |
Story 5 | Started, not done |
Story 6 | Started, not done |
Story 7 | Not started, not done |
Story 8 | Not started, not done |
The team had estimated and thought it could finish all these stories in the iteration. The team thought that each story would take one day. It discovered that stories 2, 3, and 4 took much longer than expected. Why were these stories taking more than one day and why had the team started stories 5 and 6 and not finished them?
The team realized its board didn’t describe the team’s flow. The team learned what its flow was: it hadn’t put WIP limits on the stories waiting for Check with UX or Integrate UX Fixes. (See the figure.) Until the team measured its cycle time, it had no idea that it had the wait state of Check with UX or the rework in Integrate UX Fixes.
The team’s estimates were correct—the work inside the team was one day or less. However, it depended on other people and information in the organization to complete its work. Once the team realized that, it could decide what to do.
Cycle time helps the team see its flow and if it has bottlenecks. Cycle time might also be feedback for the product owner, to see that the stories are too large.
You can read average cycle time off a cumulative flow diagram. I don’t recommend that, though, because I often want to see the variance. Teams have to measure their cycle time to see the variance, which is why I recommend measuring, not reading off a cumulative flow diagram.