The team I was with last year would exercise new language/library features (C# was their bread and butter) on one section of the system. A kind of test refactoring/development to answer the questions: Is this useful for us, do we like it, and do we understand it well enough to refactor more of the system with it.

If the answer to any of those was no, they'd revert the test stuff but keep it in mind for the future (as they'd experienced it they could make a more informed decision later if it were relevant again). This let the developers get a bit more novelty in their otherwise dull (not in a bad sense, but not interesting) enterprise projects. It was also disciplined enough that if a feature was useful (did the job) but didn't aid in other ways (clarity, time to develop, etc.) then it was quickly dropped rather than letting someone run amok in the codebase.

Timewise this was 1-2 sprints for them, one to ramp up, the second to really exercise it. The customer wasn't losing much time (they still did other work during the sprints, they didn't halt things to do this it was one story among many) and potentially gained (if it turned out to be useful).