(2019-09-04) Rothman Measure Cycle Time Not Velocity

Johanna Rothman: Measure Cycle Time, Not Velocity I'm not a fan of measuring velocity. Velocity is a point-in-time measure of capacity. That means that when things change for the team or in the code, the velocity often changes.

Instead, I like to measure cycle time. Cycle time is the entire time it takes a team to finish something on their board.

We want more collaboration and smaller stories in any agile approach.

Collocated teams who collaborate on small stories tend to have short cycle times. Distributed teams who can't collaborate, even on small stories, tend to have longer cycle times.

Cycle time is all the work time plus all the wait time.

I like to measure cycle time for a week or two to see what the cycle times look like before I can use an average.

*This story has a cycle time of 5.25 hours, of which only .5 hours is wait time.

Since the wait time is less than 10% of the total time, I wouldn't worry much about that much wait time.*

Map the Value Stream for a Team Where People Work as Individuals

Their team's cycle time is 18.25 hours. Look how much of that is wait time: 10 hours. More than the work time.

The wait time for cycle time is why thinking in flow efficiency is so important. And, for thinking about how to collaborate as in pairing, swarming, or mobbing. Anything that keeps the team's WIP to one item will lessen the wait time in the team's cycle time.

In Create Your Successful Agile Project, I recommend against velocity or using story points. Instead, I recommend teams measure and use their cycle time to see how long a story takes. (I also recommend you count stories. It doesn't matter what the points are. If your team always finishes two stories in an iteration, you have a cycle time of 5 days. You don't have to estimate anything. All you have to do is discuss the next two stories.)