Vision = reality
As discussed within Estimations, an allowance should be available for developers to de-risk certain features during development. The first step when using this allowance is to identify features that are too high-risk for development and therefore should fail your Definition of Ready. Once these have been identified, a tech spike could be used to time-box and explore the complexity and/or unfamiliarity around a specific feature. The focus of a tech spike should not be about delivering a work feature, but instead achieving a set of learning objectives.
There are generally two ways to allow time for tech spikes:
Within Iteration: Simply put, the delivery team should treat the time-boxed tech spike like any other ticket and include it within their iteration’s estimations. This means that within the time-boxed iteration, there should be time allocated for one or more developers to de-risk this feature.
External to Iteration: For higher priority de-risking exercises, it is possible to pause the following iteration in favour of investigating the feature. This results in the entire team focusing on the feature, which should result in a faster resolution, but at the cost of starting the next iteration.