Why reducing cycle time increases output

For this article, let’s compare two factories. Both factories produce the same type of goods, say, identical pieces of furniture. Perhaps they’re producing it in license or something. Anyhow, you can’t tell from the furniture from which of the two factories it came. Both factories also produce the same output, let’s say they produce 20 pieces of furniture per week. Of course, there must be some difference somewhere, otherwise It would be rather boring, wouldn’t it? Indeed there is: factory A produces batches of 20 pieces, so when starting at Monday, there output is zero. Up until Friday in the afternoon, the end of the day: then suddenly they deliver 20 pieces of furniture. But factory B, instead of delivering everything at the end of the week, is able to deliver 4 pieces at the end of every day.

Read more: Why reducing cycle time increases output

Now superficially speaking there is little difference. But think from the customer perspective: when a customer orders 4 pieces of furniture at factory A, he needs to wait at least one week before he gets delivered anything. When he instead orders his furniture at factory B, then he might already have it delivered by the end of the next day. This means that the total time that customers have to wait for their orders at factory B can be much shorter, even though both factories have the same output.

Cycle time explained

Now you may ask, what does this have to do with writing software? This is just about the batch size of a production facility, isn’t it? And software cannot be delivered in batches.

Right as that is, but there is a comparable concept. This is called cycle time: the time that it takes for a feature to be delivered, measured from the instance that work on the feature starts. Or, phrased in Scrum terms: the time that a user story spends between the sprint backlog until it is moved to Done.

As a side note, there is also a related metric called the Lead time: this is comparable to the cycle time, but measurement starts as soon as the story enters the product backlog.

It is important to stress that the cycle time is only meaningful when we’re talking about end to end functionality. That’s because only end to end functionality adds value to the product.

Why would I…?

“Reducing cycle time increases output”, as the title of this article says. Why would that be? After all, in the example, both factories had the same output when the time span is taken long enough.

It depends on how output is measured. If it is expressed as the number of items (or story points) delivered, then indeed it seems like the output of both approaches is the same. But when output is defined as value delivered to the customer, the moment of delivery begins to matter. After all, a feature represents some sort of added value for the customer. The earlier the customer gets the feature, the earlier he also gets the value of it. Especially when it is a business customer, the sooner the feature is delivered, the earlier it earns money.

But there are also other subtle aspects that cause the output of the team with the lower cycle time to win in the long run.

• A cycle time reduction in fact reduces risk. The reason is twofold: a short cycle time means that a relatively small change is delivered, so this automatically lowers the risk. And smaller problems are easier to cope with. But risk is also reduced because unexpected problems usually only show up until a feature is integrated. And with unexpected I mean: the problems that you even couldn’t think of when doing a risk assessment. The problems of which you didn’t know that you didn’t know them. So integration better happen sooner than later. That is also why it is so important to define stories using the INVEST principles.
• Elaborating on the previous point: the development cycle of a story is also a feedback cycle. You’ll only get feedback on the story’s value when the user can start using it. A shorter cycle time means that you can learn faster what the user really needs. This knowledge is valuable: it can be used to make better decisions about which feature to start working on next.
• A reduced cycle time also makes progress better visible. If you need to deliver in three months, it really helps when you in the first few weeks already have an idea whether you’re going to make it or not. The earlier you know this, the more possibilities you have to do something about it.
• Not only progress becomes visible, but also problems that remained hidden become more apparent. If you want to reduce the cycle time, but you’ve hit a barrier, then it is clear that some problem is looming. For example, you may notice that you can’t deliver faster because of lots of disturbances. This is not a problem of itself, but rather a chance to find the problems and be able to tackle them.
• Apart from that, since a reduced cycle time also reduces risk, it also makes it much better possible to stay on schedule. Delivering in time is one of the greater challenges in the software development industry.
• Shorter cycles also mean that flexibility is increased. Combined with the fact that you’ll be learning faster, shortening cycle times will cause teams to provide much more value over time.