Time to learn (T2L) is the latency between the start of build process and learning based on feedback from actual usage from customers. Put in other words: it’s the time between starting the development of new functionality, features or improvements including delivering or releasing it to customers and also the time it takes to gather enough data and feedback from actual users to learn and make choices accordingly.

Do you have an example?

Let’s have a look at an example. In the beginning of January a team starts to refine, work out the first details and make the first implementation of a new feature. It’s deployed to customers in May. The gathering of usage data and customer feedback takes 3 months. At the end of September the lessons learned are presented, new ideas are added to the backlog, priorities are re-assessed and some existing Product Backlog Items are removed. The total T2L is 9 months: from beginning of January until the end of September. So in this example, the organization took 9 months to learn whether the feature brought any value.

• January - start refinement
• May - deploy to customers
• August - gathered usage statistics
• September - lessens learn

Total: 9 months = T2L.

But how can I convince my stakeholders?

The T2L metric itself is a new metric, but the idea behind this metric is common sense. If your stakeholders just push you and your teams for more features or an higher velocity, you can use the following to trigger them:

• Good idea, how could we measure the success of this feature in the first weeks/months after releasing it to customers?
• During a sprint review, show also the usage statistics of the things built 3 months ago. If the results are unknown or insignificant, make a suggestion to learn faster from the things built in a sprint.
• When stakeholders want additional features before you ship it to customers, suggest a smaller target audience and emphasize that you want to learn from the things already built before you increase further costs.

3 benefits of an improved T2L

1. Upfront discussion on what we want to achieve

When the team routinely starts applying T2L, it’s more likely to be focused on what they really need to achieve as a team. They ask questions of the work such as: when is a feature successful? When 1.000 users use it daily? When the conversion on the website has increased by 5%? How are we going to measure success? When the team starts thinking about T2L it is often easier to focus on value with both the work undertaken and the solutions selected.

2. Focus on learning more, and not on doing more

Presenting this T2L during the sprint review often removes the focus on the velocity and the details of the planning. Of course how effective development is important, but only in the context of doing the right thing or delivering the right learning. When stakeholders get transparency on the outcome and impact of the features delivered several sprints ago, the mindset of the meeting shifts. It shifts more to long term goals based on value such as usage, market penetration and customer satisfaction. This often results in quicker experiments, learning from actual data and finding improvements more rapidly.

3. Faster learning is faster value

With a short T2L the organization can learn a lot faster on many fronts. The team starts to understand the customer demands better, because it sees if the new functionality or added features are used or not. The Product Owner learns what delivers actual value and what does not. With a long and slow learning loop, so much new functionality is added that it’s hard to deduce what actually improved it. With a short T2L, it’s much easier to know what led to the improvement and therefore what is of real value and what is not.

Additionally, the team gets quick feedback on the quality of their work so they know more quickly what to improve on their craftsmanship. Stakeholders also start to see which ideas were actually good ideas and what the customers really need.