Skip to content

Skills Sprint

Principle · All principles
Evidence · 13 claims (3 for, 8 mixed, 2 against) · 26 studies (8 causal, 8 quant-synthesis, 4 review, 3 theoretical, 2 design, 1 qualitative), q1–q4 · 7 of 26 report an effect size · 5 claims rest on one study

Conditional relationship

A skills sprint is a time-boxed cycle (from one session to about two weeks) in which learners produce or test one scoped deliverable against stated criteria, get feedback partway through, revise, and finish with a review. This page owns the time box and its cycle: for learners who can already carry out the component skills of the task (intermediate on those skills, or adults working on problems from their own work), organising practice of a complex-skill as a short cycle around one deliverable, with criteria written before work starts, at least one checkpoint where the work is reviewed and then revised, and a structured debrief at the end, is expected to produce better whole-task skill-performance and near-transfer than the same time spent on an open-ended project with vague goals, or on isolated exercises that never meet in one task. The pressure of the deadline is not the active ingredient in this model: the scope, the criteria, the review-and-revise loop and the debrief are.

No claim in the wiki tests a skills sprint, against a longer project, against the same work without a time box, or against part-task exercises. The two claims that describe sprints report no outcome data (below). What the wiki does hold is evidence on the cycle's ingredients, each from another setting and carried here by extrapolation: specific, difficult goals raise task performance on work and laboratory tasks, by less on complex tasks; for novice learners, process goals beat outcome goals and minimal guidance does worse than explicit instruction; contingent support beats fixed or absent support in one-to-one tutoring; task- and process-level feedback beats feedback about the person; structured reflection prompts beat generic ones; and in one small fault-diagnosis experiment forced pacing removed the transfer that unpaced training produced. So the relationship is conditional on the learners' readiness for the whole task, on whether anyone can review work at the checkpoint, on whether the time box leaves room to reflect, and on the horizon. The design below is a labelled default.

How the converted neighbours sit beside this page. Problem-based Learning owns the general relationship for a problem- or project-centred unit (how much guidance novices get, problem-first or instruction-first); a sprint is one way to time-box such a unit, and this page does not repeat that model. Goal Setting & Monitoring owns what a goal should be (specific, challenging, process or outcome) and how progress is made visible; this page uses it for the sprint's criteria. Feedback Loops owns whether a review leads to a changed next attempt; the sprint's checkpoint is one such loop. Debriefing owns the facilitated conversation after the sprint. Experiential Learning owns the general do–reflect–try-again relationship. Authentic Audiences and Purposes owns what a real audience changes in a product, and the Learning by Producing pattern carries a longer production unit.

Default design, while the relationship is untested

The earlier page's guidance, kept as a concrete default a designer can act on and revise. Each step is a proposal; its evidence status is beside it. The minutes assume a one-day sprint of about six working hours; scale each segment to the time box the brief gives.

  1. Check readiness before the sprint, not during it. Before the sprint, give each learner one short task that uses the component skills the deliverable needs (10–15 minutes). A learner who cannot do it gets part-task practice or worked examples on that skill first, or a role in the sprint that does not depend on it. Basis: for novices, isolating parts of a high-interactivity task first reduces load (Part-task practice reduces cognitive load for absolute novices during initial skill acquisition. [~M]) and minimally guided work does worse than explicit instruction (Minimal guidance is less effective for novices than explicit instruction [-S]); neither tests a sprint. The readiness task is an untested proposal.
  2. Scope one deliverable and write its criteria before work starts (kickoff, about 30 minutes). Name the deliverable, what "done" means, and three to five quality criteria that a reviewer can check, including at least one about how well it works, not only whether it was finished. Agree roles and how the team will talk. Basis: specific, difficult goals raise task performance on work and laboratory tasks (Specific, difficult goals lead to higher performance than easy or vague "do your best" goals. [+M]), by less on complex tasks (Goal setting improves performance [~S]); carried to sprints. The number of criteria is an untested proposal.
  3. For learners new to the task, set the criteria as steps, not only as the result. Write criteria that name the process ("tested with two users before revising", "checked the calculation against a second method") beside the product criteria; drop the process criteria in later sprints once learners meet them unprompted. Basis: Process goals lead to better skill acquisition for novices than outcome goals. [~M] (high-school writing revision; one experiment and a chapter), carried to team sprints.
  4. Work in blocks of 60–90 minutes with a checkpoint after each (15–20 minutes). At each checkpoint the team shows the current state against the criteria, the reviewer (coach, peer team or user) says what meets a criterion and what does not, and the team names one change for the next block. Feedback is about the work and the method, not the people. Basis: task- and process-level feedback supports learning more than feedback about the self (Feedback Most Effective At Task And Process Levels [+S], general feedback meta-analyses carried to sprint reviews). Block length and checkpoint length are untested proposals.
  5. Coach contingently during blocks. A coach who sees a team stall gives a cue first, then a more specific hint, then a demonstration of the step, and steps back after a success. Basis: Contingent scaffolding improves learning more than fixed or absent support. [~M] (mostly one-to-one tutoring; its classroom-scale effect is not shown).
  6. Keep the last 60–75 minutes unhurried: a test or demo, then a debrief. Stop building with about an hour left. Spend 20–30 minutes testing the deliverable against the criteria (or showing it to its user), then 30–45 minutes on a structured debrief: what happened, two or three decisions and why, which criteria were met, and one change each learner will try next sprint. Do not let the deadline eat this time. Basis: structured reflection prompts beat generic ones (Reflective Practice Improves Outcomes When Structured [+M]); in one fault-diagnosis experiment forced pacing removed the transfer unpaced training produced (Forced pacing eliminates positive transfer from computer aiding and leads subjects to use strategies requiring many more tests than necessary [-M], twelve subjects). How to run the debrief is modelled in Debriefing. The times are untested proposals.
  7. Make each member's contribution visible. Give each learner a named part of the deliverable and ask each to explain one decision at the debrief, so the strongest member does not carry the team. Untested proposal, from the earlier page's caution about team imbalance.
  8. Keep the task whole once learners are ready for it. After the readiness check, the sprint works on the whole deliverable, not separate exercises; a component that keeps failing gets a short side-practice and goes back into the whole. Basis: A training-design argument, not tested by any study recorded here, holds that practising whole complex tasks improves transfer of complex skills [~M] (an argument, not an experiment).
  9. Plan a run of sprints, not one, with support withdrawn across them. A default arc for three to six sprints over a term or a work project: early sprints with a deliverable and criteria set by the coach, process criteria included, a coach-run checkpoint after every block and a coach-led debrief; middle sprints in which learners draft part of the criteria and peers review at the checkpoints, with the coach checking in at one checkpoint only; late sprints in which learners scope their own deliverable, run their own reviews, and the coach joins the debrief only. A learner or team moves to the next stage after two consecutive sprints whose deliverable meets the criteria and in which each member can explain a decision at the debrief; a team that misses criteria twice returns to coach-set scope and coached checkpoints. The arc and its thresholds are untested proposals. One descriptive instance runs seven two-week sprints in a student robotics project (In a winter 2025/2026 student project, a student team incrementally built a ROS2 software ecosystem for automated disassembly of brick assemblies across seven sprints [~W], no outcome measured).

When a condition is not met: if learners cannot yet do the component skills, teach them first (step 1) rather than running the sprint and hoping; if no one can review work at a checkpoint, use a written checklist of the criteria that teams score themselves against, plus one peer team's review, and keep the coach for the debrief; if the time box is too short for a debrief, shrink the deliverable, not the debrief.

Fitting the design to a situation

The three facts that most change the decision:

  • Whether learners can already do the parts. A sprint integrates and applies skills under a deadline; it does not teach them from scratch, and novices fall behind fastest. If unstated, ask: can each learner do, alone, one small task using each skill the deliverable needs?
  • Who reviews the work partway through, and how much of their time there is. The cycle depends on a checkpoint that changes the next block of work. If unstated, ask: who will look at each team's work before the end, how often, and for how many minutes per team?
  • What the sprint is for: the learning, the product, or both. A deliverable someone will actually use pulls attention to finishing; learning needs the debrief and the criteria to stay visible. If unstated, ask: what must learners be able to do afterwards, unaided, and does the product have a real user or audience?
If the brief says… Then change… Basis
Learners are novice on the component skills Do not start with the sprint. Teach the components with worked examples or part-task practice first; run the first sprint on a smaller deliverable, with process criteria and a coach at every checkpoint Minimal guidance is less effective for novices than explicit instruction [-S]; Part-task practice reduces cognitive load for absolute novices during initial skill acquisition. [~M]; both carried to sprints from other tasks
Learners are advanced, or experienced staff Let them scope the deliverable and write the criteria; checkpoints become peer reviews; spend coach time on the debrief and on stretching the criteria untested proposal; the late-sprint stage of the arc above
Learners are child or adolescent Shorter blocks (20–30 minutes), a deliverable finished within one or two lessons, criteria given as a short checklist with pictures or examples, teacher at every checkpoint, explicit roles untested proposal; the goal and feedback evidence above is from adults, older students and work tasks
Adults in a work setting, on a problem from their own job Let them bring the problem and the deliverable (a changed procedure, a tool, a brief to a manager); keep criteria in the workplace's own terms; schedule blocks around shifts; end with the change tried at work and reported at the next sprint untested proposal, from the earlier page's sources on workplace sprints (Longmuss & Hohne 2017), which have no claim page here
The goal is a concept or principle learners have not met yet Teach it before the sprint, or use the sprint only as the application after instruction; check understanding unaided after the debrief, not only by the product Minimal guidance is less effective for novices than explicit instruction [-S]; see Problem-based Learning for problem-first designs
Only one session, with a fixed short time budget (e.g. 90 minutes) One deliverable, revised once: kickoff and criteria 10 min, build 30 min, checkpoint 10 min, revise 20 min, test 5 min, debrief 15 min (90 in all); shrink the deliverable before cutting the checkpoint or debrief untested proposal; the debrief's place rests on Reflective Practice Improves Outcomes When Structured [+M]
One coach or teacher for many teams, or scarce facilitator time (volunteers, a busy shift) Stagger checkpoints so the coach sees each team for 5 minutes per checkpoint; between visits, teams score their work against a written criteria checklist and swap with one peer team; the coach leads one whole-group debrief untested proposal; contingent support evidence is mostly one-to-one (Contingent scaffolding improves learning more than fixed or absent support. [~M])
Mixed modes: some learners remote, some in the room, or some on phones only Put the deliverable, criteria and checkpoint notes in one shared document everyone can edit or comment on from a phone; give remote members a named part; at checkpoints the remote member presents first; keep camera-off options for the debrief untested proposal
Online and self-paced, no live coach Split the sprint over days with a fixed deadline per block; checkpoints are a self-check against the criteria plus one asynchronous peer review; the debrief is a structured written reflection (what happened, one decision and why, one change) untested proposal; the written reflection step rests on Reflective Practice Improves Outcomes When Structured [+M]
Learners have low confidence or low literacy Smaller deliverable, criteria shown with examples rather than text, roles chosen so each learner starts with a part they can do, debrief spoken rather than written, feedback on the work and method only untested proposal; the last point draws on Feedback Most Effective At Task And Process Levels [+S]
The product goes to a real audience or user (a client, a manager, the public) Keep a test with that user at the end; separate the version the audience sees from the learners' notes and reasoning, which stay in the debrief; criteria come from what the user needs untested proposal; see Authentic Audiences and Purposes
The work uses private or sensitive material (client records, staff problems, learners' own situations) Learners decide what goes into the shared deliverable and who sees it; use anonymised or invented cases at checkpoints if a team prefers; the debrief discusses decisions, not the private content untested proposal
The brief names its own routine (a stand-up, a retrospective template, a rubric, a design-sprint schedule) Keep it. Run it as given, and change only what the evidence above bears on: criteria written before work starts, one review-and-revise checkpoint, and an unhurried debrief that ends with a named change untested proposal; the three changes rest on the claims in steps 2, 4 and 6
The brief gives its own categories, criteria or rubric Use them as the sprint's criteria; do not substitute these. If the rubric rewards use of a tool, keep that criterion and add one unaided check beside it untested proposal
The brief wants a whole-task performance kept whole (a full presentation, a full repair, a whole product) Keep it whole in the sprint; put any practice of a weak part in a short side-block and return to the whole A training-design argument, not tested by any study recorded here, holds that practising whole complex tasks improves transfer of complex skills [~M] (argument only)
Time pressure itself is part of the target (incident response, live service) Keep the forced pace in later sprints only, once the task is learned unhurried, and always follow a paced run with an unpaced debrief Forced pacing eliminates positive transfer from computer aiding and leads subjects to use strategies requiring many more tests than necessary [-M] (twelve subjects, fault diagnosis); Letting learners pace instruction helped on complex material in one experiment, while learner control in general showed almost no effect across 18 studies [~M]
Stakes are high, or the assessment is individual and unaided Judge each learner on an individual unaided task after the sprint, not on the team's deliverable; keep the sprint for practice untested proposal
The brief reports an error learners actually made (shipped without testing, one member did everything) Use it at the first kickoff as a compared case: show a past deliverable with that error beside one without it, and turn the difference into a criterion untested proposal

Four of the eighteen rows rest on a claim (novices, an unfamiliar concept, a whole task, time pressure), each carried to sprints from another task or population; four more are untested proposals that cite a claim for one part of the move (the debrief, coaching, written reflection, feedback about the work); the other ten are untested proposals.

Observation, state and explanation

What can be observed in a sprint: the deliverable at each checkpoint against each criterion, what the reviewer said, what the team changed in the next block, who did which part, how the time was actually spent, what each learner says at the debrief, and what each can do on an individual task afterwards. "Learned to collaborate", "integrated the skills" and "has momentum" are inferred states. A finished deliverable shows what the team produced with the help available; it does not show what each member can now do alone.

Response Plausible explanations Observation that could change the interpretation
The deliverable meets the criteria, but members cannot explain its key decisions One member did the work; the decisions came from the coach's hints; criteria rewarded finishing, not understanding Ask each member to explain one decision and redo one part alone; check who wrote which part.
The team stalls in the first block and never recovers A missing component skill; scope too large; unclear roles; conflict in the team Ask each member to do a small piece of the component task alone; ask each to state the deliverable and their part.
The checkpoint feedback is not used in the next block Feedback too vague; no time to act on it; the team disagrees with it; the change named was too large Ask the team to restate the feedback and the one change they chose; look at the next block's work for it.
Strong product, weak debrief ("it went fine") Debrief cut by time; no prompts; learners unwilling to name errors in front of others Use written prompts at three decision points; offer a private written option; check whether the debrief started on time.
Good performance in the sprint, weak on a similar task a month later The sprint carried the decisions; little transfer of the method; no later practice Give an individual task with the same structure and new content at the delay, and record what happened in between.

These rows are proposals, untested with learners as diagnostics. A probe changes what it measures (asking a member to explain a decision is itself practice), so record each one and keep the explanations that remain open.

Evidence and qualifications

No claim in the wiki compares a skills sprint with another way of spending the same time. The claims below test parts of the cycle in other settings; learners, tasks and outcomes differ across them, so do not rank them by effect size.

  • Specific, difficult goals lead to higher performance than easy or vague "do your best" goals. [+M]: one narrative review (Locke & Latham 2002) of goal-setting research on task performance, coded q2; no source text was available to check and no effect size is printed. It supports writing specific, demanding criteria before the sprint. It is about task performance in general, not learning. Its own Related Claims list it as a possible duplicate of the next claim.
  • Goal setting improves performance [~S]: two meta-analyses, both read as abstracts. Across 125 work and laboratory studies, specific difficult goals raised performance by d = .76 on easy tasks and d = .42 on the most complex ones (business simulations, engineering work, research); across randomised trials of behaviour change, mostly in health, setting a goal had a small effect, d = .34. Neither studies academic learning. It qualifies the sprint's criteria: the goal effect is smaller on exactly the complex tasks sprints use.
  • Process goals lead to better skill acquisition for novices than outcome goals. [~M]: 84 high-school girls learning a writing revision skill did better with process goals than outcome goals, with a suggestion that outcome goals help once the skill is mastered; plus a theoretical chapter. No effect size printed. It qualifies a sprint whose only goal is the finished deliverable when learners are new to the task.
  • Contingent scaffolding improves learning more than fixed or absent support. [~M]: five studies on the page; its table gathers 20 distinct studies behind it and narrower claims. Fourth and fifth graders tutored one-to-one in long division under fully contingent support solved more problems than under fixed or no support, at an immediate and a one-month test (8 per condition); a meta-analysis of dynamic assessment ranked explicit strategy training above scaffolding. The claim's own Discussion says the evidence is mostly one-to-one and contingency is scarce in whole-class teaching. It supports coaching during sprint blocks; it does not show the effect with one coach for many teams.
  • Feedback Most Effective At Task And Process Levels [+S]: two meta-analyses: high-information feedback had a very large effect (d = 0.99, k = 42) across educational studies, and feedback drawing attention to the self rather than the task was less effective, with over a third of feedback interventions lowering performance (d = .41 on average). It supports checkpoint feedback about the work and the method. It does not test feedback within a sprint.
  • Reflective Practice Improves Outcomes When Structured [+M]: a meta-analysis of 48 school writing-to-learn studies in which metacognitive-reflection prompts were the one content moderator linked to larger effects, and a quasi-experiment with 208 first-year engineering students in which specific prompts beat generic ones with the number of reflections held constant. No randomised comparison is recorded. It supports a prompted debrief over "how did it go?".
  • Forced pacing eliminates positive transfer from computer aiding and leads subjects to use strategies requiring many more tests than necessary [-M]: one 1980 technical-report experiment with twelve subjects on computer-aided fault diagnosis; forced-paced subjects showed no transfer of training, and the authors suggest learners "may have to be allowed to reflect" on what the aid does. Coded r1. It is the only claim here about time pressure and learning, and it limits the sprint: a deadline that leaves no room to reflect may leave the product and not the skill.
  • Minimal guidance is less effective for novices than explicit instruction [-S]: three studies on the page and 13 distinct studies in its table; across 580 comparisons explicit instruction beat unassisted discovery (d = 0.38), while discovery with feedback, worked examples or scaffolding beat other instruction. It limits sprints for novices and supports the coached, criteria-led version.
  • Part-task practice reduces cognitive load for absolute novices during initial skill acquisition. [~M]: one experiment in which novices on high-interactivity material did better with parts first, then the whole; no effect size printed. It supports teaching components before a sprint for learners with very low prior knowledge.
  • A training-design argument, not tested by any study recorded here, holds that practising whole complex tasks improves transfer of complex skills [~M]: a training-design article (van Merriënboer, Kester & Paas 2006), not an experiment; it also proposes lowering task complexity early for novices. It is the rationale for keeping the sprint's task whole, and no more than that.
  • Letting learners pace instruction helped on complex material in one experiment, while learner control in general showed almost no effect across 18 studies [~M]: primary-school students learned more from learner-paced than system-paced animation on difficult questions only, while a meta-analysis of learner control found an overall effect near zero (g = 0.05). It bears on pacing only at a distance and is cited for the time-pressure row.

The earlier page tagged the whole-task and specific-goals claims [~S]; each rests on one study coded q2, so they are capped at M here.

The evidence by question

Further evidence, not yet read against this model

Claims that mention sprints. None measures an outcome, so none tests the relationship.

Objective and learner-valued goal

The designer's objective is usually unaided performance of the integrated skill on a new task of the same kind, at a stated horizon, by each learner, not only the team's deliverable. Elicit separately what learners want from the sprint: a product they can show or use, to solve a problem at work, to look capable in front of colleagues, to get it over with. Agreement and divergence are both observations. A learner who values the product may take over the team's work and leave others watching; one who values not looking slow may hide a missing skill until the deadline.

For example, staff in a workplace improvement sprint may want the bottleneck in their own process fixed by Friday, while the designer's objective is that each can run a small test of a change on their own later. A sprint that fixes the bottleneck serves the staff's goal; asking each to plan, alone, a test of a second change after the debrief tests the designer's. Record both, so that a fixed bottleneck is not read as the capability.

What would revise this model?

The expectation should weaken if comparisons of time-boxed sprints with the same time spent on a longer project or on structured exercises, with comparable learners and individual unaided outcomes, show no advantage, or show that a sprint's gain in the product does not appear in individual performance later. If sprints run without a checkpoint or a debrief do as well as those with them, the cycle's ingredients are not what matters here. If forced pacing turns out to help rather than harm transfer for learners who already know the task, the warning about deadlines should be narrowed to novices. If goal effects on complex learning tasks are as small as on complex work tasks, the criteria step should be weighted less. Do not protect the model by calling every failure "scope too large" or "not enough coaching" after the fact.

A finished deliverable, each learner's unaided performance after the sprint, delayed retention, transfer to a new task, and use at work are separate claims. The present evidence establishes no sprint length, no checkpoint frequency and no criterion for moving learners on.

Examples

  • Design sprint: Teams prototype a service, test assumptions, and present a revised concept within a week.
  • Research sprint: Learners gather evidence, synthesize findings, and brief stakeholders on a bounded question.
  • Workplace improvement sprint: Staff identify a process bottleneck, test a small change, and document results.
  • Skill-build sprint: Learners practice a targeted toolset intensively while producing a shared artifact.

Key Sources

  • Banfield, R., Lombardo, C. T., & Wax, T. (2015). Design sprint: A practical guidebook for building great digital products. O'Reilly Media.
  • Knapp, J., Zeratsky, J., & Kowitz, B. (2016). Sprint: How to solve big problems and test new ideas in just five days. Simon & Schuster.
  • Longmuss, J., & Hohne, B. P. (2017). Agile learning for vocationally trained expert workers: Expanding workplace-based learning one sprint at a time. Procedia Manufacturing, 9, 262-268.
  • McBurney, J., Hunt, S. L., Gyendina, M., & Brown, S. J. (2020). Library research sprints as a tool to engage faculty and promote collaboration. portal: Libraries and the Academy, 20(2), 373-396. https://doi.org/10.1353/pla.2020.0016
Page metadata
Field Value
type principle
id skills-sprint
title Skills Sprint
description For learners who can already do the component skills, a short time-boxed cycle around one scoped deliverable, with criteria set before work starts, a mid-cycle review and revision, and an unhurried structured debrief, is expected to build whole-task skill better than open-ended projects or isolated exercises; no claim in the wiki tests sprints, and the evidence is on goals, feedback, coaching, reflection and time pressure in other settings.
status review
canonical True
generated by claude/unspecified on 2026-10-15
trust unverified — no one has confirmed this page's content
sources 2 — longmuss-2017, mcburney-2020

Frontmatter is the page's machine-readable record — see the Schema & Guide.