10% time only works if the team uses it intentionally and reviews it honestly. This retro format tracks what got explored, what got learned, and what should continue — turning protected time into protected investment. Snap it and make the learning visible.
Run the 10% time retro at the end of each sprint or month in teams that formally allocate exploration, learning, or innovation time. It's the accountability check that makes 10% time sustainable: without a review, it gradually gets absorbed by feature work.
This format is also useful for any team that informally protects learning time (side projects, tech spikes, conference attendance, open-source contributions) but doesn't systematically review what it produced.
Everything the team invested 10% time in during the sprint: tech spikes, prototype builds, learning resources, experiment designs, side project experiments. One sticky per initiative. This column is the time ledger — it makes the investment visible before evaluating its return.
The actual output of each exploration: technical insight, validated or invalidated hypothesis, new capability acquired, experiment result. Map each learning to the exploration that produced it. Explorations without corresponding learnings are a signal — either the time wasn't used or the learning wasn't captured.
Explorations that produced learnings worth investing more in — tech approaches worth productizing, experiments worth repeating at scale, skills worth developing into team capabilities. This column justifies the 10% allocation: it shows what the protected time is producing for the team and the product.
Explorations that didn't produce value and shouldn't continue. Dropping an exploration isn't failure — it's information. A team that only continues explorations and never drops them isn't being honest about return on learning investment.
Proposed explorations for the coming sprint, based on what was learned and what's been taken forward. Planning the next 10% allocation at the retro makes the time intentional rather than incidental.
Pull up the previous sprint's 10% plan. Did the team actually explore what they planned? If not, why not? Feature pressure absorbing 10% time is the most common failure mode — name it explicitly.
Write each exploration on the left and its learning on the right. Connect them with a line. Explorations with no corresponding learning get a question mark — discuss what happened.
For each exploration-learning pair, decide: take forward or drop? Be honest. A prototype that proved the idea won't work is a valid learning — drop the exploration without guilt.
Based on what's being taken forward, define the next sprint's explorations. Each exploration should have a clear hypothesis: 'If we spend one day exploring X, we expect to learn Y.' Hypothesis-first makes the learning intentional.
Snap the board with BoardSnap. The AI reads the exploration-to-learning map and the next sprint's plan — outputting a learning investment report that justifies the 10% allocation to anyone who questions it.
10% time is the first thing that gets cut when delivery pressure increases. A visible board of explorations and their learnings makes the case for protecting the time more effectively than any verbal argument. The physical artifact shows the team's learning portfolio in one place.
BoardSnap reads the exploration-to-learning structure and outputs a learning portfolio summary that can be shared with leadership. Sprint over sprint, the snapped boards build a record of what the team's protected learning time has produced — making the business case for protecting it concrete and defensible.
10% time (sometimes called 20% time or innovation time) is a practice where teams formally allocate a percentage of their sprint capacity to exploration, learning, and experimentation — distinct from feature delivery. Google famously used a 20% time policy. The practice is most effective when the time is genuinely protected, the explorations are hypothesis-driven, and the outputs are systematically reviewed in a session like this retro.
Two things work: making 10% time a first-class entry in the sprint plan (not a nice-to-have residual), and running this retro every sprint. The retro creates accountability — if the team can't report what they explored, the time wasn't protected. Over time, that accountability becomes the cultural norm.
Use the 'take forward' stickies from the previous retro as the starting point. New explorations should be hypothesis-driven: 'We believe X because Y; we'll test by doing Z.' Explorations without a hypothesis tend to be unfocused and produce weak learnings. The hypothesis doesn't have to be proven — it just has to be specific enough to be testable.
Use this template as a retroactive audit. Ask: 'What learning or exploration did we actually do this sprint, formally or informally?' Map what happened and what was learned. Most teams invest more time in exploration than they realize — making it visible is the first step to making it intentional.
No exporting, no transcription. Snap the board, get the action plan.