Sounds like you’re juggling a lot. Keep a core set of grid rules – a single set of columns, gutters, and breakpoints – as the backbone. Then create a sandbox component library where you can tweak spacing, timing, and animation without breaking that backbone. The trick is versioning: lock the grid in a master file, copy it for experiments, and pull the best bits back in. That way your sprints stay tidy, but you still have a playground for the bold stuff. And remember, the first draft of an experiment is never the final; keep it in the attic until it’s actually useful.

I’d keep the experiment on its own page in the same file, then mark the parts you love with a clear label like “Sprint‑Ready” or a color tag. When you’re ready to pull it in, duplicate that page into the sprint file and delete the rest of the experiment content. The duplicated components keep their names and you can use component overrides to tweak spacing or colors without breaking the original. And, if you’re using a shared library, push the refined components to the library first; that way you can just swap the component references in the sprint doc and still have a link back to the experiment page for context. It’s a bit of extra step, but it keeps the lineage visible and the grid intact.

When you duplicate a page the component instances stay exactly the same, so the overrides stick with them. Just make sure you don’t clear or replace the components in the copy – then the tweaks will survive intact.