Planning and Customizing Your Design Sprint 2.0 Agenda
This skill teaches you how to structure a complete multi-day sprint agenda, adapt the classic five-day format into compressed design sprint 2.0 or four-day variations, and prepare all logistics so your team can focus entirely on the work.
Start by identifying your sprint challenge and available days. Map the core activities (understand, sketch, decide, prototype, test) onto your timeline, allocating roughly equal time to each phase. For a design sprint 2.0 compressed into four days, merge the understand and sketch phases into day one. Prepare all materials, recruit test users, and share the agenda with your team at least one week before the sprint begins.
Outcome: You produce a detailed, hour-by-hour sprint agenda tailored to your team's timeline and constraints, with all materials sourced, rooms booked, test users recruited, and every participant briefed on expectations before day one.
Prerequisites
- Basic understanding of the Google Design Sprint phases (understand, sketch, decide, prototype, test)
- A defined sprint challenge or business question to solve
- Access to a calendar and the ability to block 4-5 consecutive days for key participants
- Familiarity with the Decider role and sprint team composition (5-7 people)
Overview
Planning a design sprint agenda is the foundational act that determines whether your sprint produces a validated insight or devolves into an expensive meeting. The agenda is not a loose outline. It is a minute-by-minute schedule that locks each activity into a time box, assigns ownership of facilitation moments, and sequences exercises so that each day's output feeds cleanly into the next day's input. Without this artifact, teams spend their limited sprint hours negotiating what to do next instead of doing the work.
Inside the Google Design Sprint framework, agenda planning sits upstream of every other activity. It is the skill you execute before mapping the challenge, before sketching solutions, and before the facilitator even introduces the sprint to the room. The agenda is also where you make your most consequential structural decision: whether to run the classic five-day format, compress into a four-day sprint by merging early phases, or adopt the design sprint 2.0 format that consolidates the entire sprint into four days with longer working sessions. Each variation changes how much time is available per exercise, which exercises you keep or cut, and how much pre-work participants must complete.
The concrete artifact you produce is a spreadsheet or document with columns for day, time block, activity name, duration, facilitator notes, and required materials. Alongside it, you produce a logistics checklist covering room bookings, supplies, prototype tools, and user test recruitment status. A well-planned agenda eliminates ambiguity. Every participant knows exactly where to be, what to bring, and what the expected output looks like at the end of each session. When this skill is done well, the sprint facilitator can focus entirely on guiding the group through exercises rather than improvising structure on the fly.
Success looks like this: on the morning of day one, every participant has received a printed or digital agenda, all materials are staged in the room, test users are confirmed for the final day, and the facilitator has rehearsed each transition. The sprint can begin on time and stay on time because the planning was thorough enough to absorb the inevitable small disruptions without derailing the larger sequence.
How It Works
A sprint agenda works because it converts an open-ended innovation challenge into a constrained sequence of divergent and convergent exercises. The underlying principle is time-boxed progression. Each phase of the sprint (understand, sketch, decide, prototype, test) produces a specific output that becomes the input for the next phase. The agenda enforces this dependency chain by allocating fixed durations and preventing any single phase from expanding to consume the entire sprint.
The classic five-day format from the Google Design Sprint assigns one full day to each phase. Day one is understanding the problem and mapping the user journey. Day two is individual sketching. Day three is reviewing sketches, voting, and deciding on a direction. Day four is building a realistic prototype. Day five is testing with real users. This format works well when teams are new to sprints, when the problem space is unfamiliar, or when the Decider needs time to absorb information before committing to a direction.
The design sprint 2.0 variation, popularized by AJ&Smart, compresses the sprint into four days by merging the understand and sketch phases into a single intense first day. This works because experienced sprint teams can move through Lightning Talks, How Might We exercises, and the mapping activity in the morning, then immediately begin individual sketching in the afternoon while the problem space is fresh. The trade-off is intensity. Day one in a design sprint 2.0 typically runs 8-9 hours instead of 6-7, and participants need stronger pre-sprint briefing materials because there is less time for exploratory discussion.
When customizing the agenda, the key mental model is activity dependency. Some exercises must happen before others. You cannot vote on sketches before sketches exist. You cannot build a prototype before the team decides which concept to pursue. You cannot test a prototype that has not been built. Within each phase, however, you have flexibility. You can adjust which warm-up exercises to include, how many Lightning Talk experts to invite, whether to use Crazy 8s or a different rapid ideation format, and how many rounds of dot voting to run. The agenda is your tool for making these choices explicit and visible.
The assumptions that can break this model are worth naming. First, the agenda assumes all key participants are available for the full duration. If the Decider can only attend two of five days, you need to restructure decision points around their availability. Second, the agenda assumes user test participants are recruited and confirmed before the sprint begins. If recruitment is uncertain, the entire sprint is at risk because day five cannot happen without users. Third, the agenda assumes the sprint challenge is well-scoped. If the challenge is too broad, the understand phase will overflow its time box no matter how well you plan. Addressing these assumptions during planning, not during the sprint, is what separates a productive sprint from a chaotic one.
Step-by-Step
Step 1: Confirm the Sprint Format and Duration
Before writing a single time block, decide which format fits your team's constraints. The classic five-day format gives one full day per phase and works best for teams running their first sprint or tackling a deeply unfamiliar problem space. The four-day format compresses understand and sketch into day one and is suitable for teams with prior sprint experience. 0 format also uses four days but restructures exercises more aggressively, moving some decision-making into day one and giving the prototype phase more breathing room on day three.
Interview the Decider and key stakeholders to understand hard constraints: are there days when critical people are unavailable? Is there a deadline that forces a shorter sprint? Document the chosen format, the start and end dates, and the daily working hours (typically 10am to 5pm with a one-hour lunch).
Tip: If your Decider is only available for three of the five days, switch to a four-day format and schedule decision exercises on days the Decider is present. Never run a sprint where the Decider misses the voting or decision moments.
Step 2: List All Activities for Each Phase
Write out every exercise and activity that belongs in each phase of your chosen format. For the understand phase, this typically includes Lightning Talks from domain experts, a How Might We exercise, affinity mapping of HMW notes, a user journey map, and selection of a target moment to focus the sprint. For the sketch phase, list Lightning Demos of competitor or analogous products, individual note-taking, Crazy 8s rapid sketching, and the three-panel Solution Sketch. For the decide phase, include the Art Museum silent review, Heat Map dot voting, Speed Critique discussions, the Straw Poll, and the Decider's final pick.
For the prototype phase, list storyboard creation, asset collection, and the build itself. For the test phase, list interview script preparation, five user interviews, and a debrief. Having every activity listed prevents you from accidentally omitting a critical exercise when you start assigning time blocks.
Tip: Keep a master list of all possible sprint exercises and mark each one as 'core' (must include) or 'optional' (include if time allows). This makes it fast to adapt when you need to shorten a day by 90 minutes.
Step 3: Assign Time Durations to Each Activity
For each exercise on your list, assign a realistic duration based on your team size and the complexity of the challenge. Lightning Talks typically run 10-15 minutes each, and you should plan for 3-5 speakers on understand day. How Might We note generation runs concurrently with talks, but affinity mapping and voting on HMW clusters takes 30-45 minutes. Crazy 8s takes exactly 8 minutes of sketching but 15-20 minutes with setup and explanation for first-time participants.
Solution Sketches need 45-60 minutes of quiet individual work. The Art Museum review needs 15-20 minutes of silent walking, then 3 minutes per sketch for Speed Critique discussion. Prototype building needs 5-7 hours depending on fidelity. User test interviews run 60 minutes each with 15-minute breaks between them, so five interviews consume about 6 hours including debrief.
Add 10-15 minute buffers between major activities to absorb overruns and allow bathroom breaks.
Tip: Never plan a day that exceeds 7.5 hours of active work time. Sprint fatigue is real, and the quality of sketches and decisions degrades sharply after hour six. If your schedule is too tight, cut optional warm-up exercises before shortening core activities.
Step 4: Sequence Activities into a Day-by-Day Schedule
Arrange activities into each day's timeline, respecting the dependency chain. Place activities that require fresh thinking (individual sketching, Crazy 8s) in the morning. Place group discussion and voting activities in the early afternoon when energy is moderate. Place wrap-up and preparation activities (reviewing next-day logistics, assigning homework) at the end of each day.
0 agenda, day one starts with Lightning Talks and mapping in the morning, transitions to individual sketching exercises after lunch, and ends with participants completing their Solution Sketches as take-home work to be submitted before the next morning. Day two opens with the Art Museum review and voting, moves into storyboarding the selected concept, and ends with a clear prototype plan. Day three is dedicated entirely to building the prototype. Day four is user testing and synthesis.
Write the schedule in a table format with columns for time, activity, duration, facilitator lead, and materials needed.
Tip: Schedule the Decider's final vote immediately after lunch on decision day. The Decider needs the break to process what they saw during the Art Museum review, but waiting until end of day risks losing them to competing meetings.
Step 5: Identify and Prepare All Required Materials
Walk through every activity on your agenda and list every physical or digital material it requires. For in-person sprints, this includes large whiteboards or wall-mounted paper, rectangular sticky notes (yellow for standard, pink or blue for HMW notes), black Sharpie markers (one per person, no thin pens), green and red dot stickers for voting, Time Timer or visible countdown timer, printed user journey map templates, and A4 or letter paper for Solution Sketches. For remote sprints, this includes a configured Miro or FigJam board with pre-built templates for each exercise, a video conferencing link with breakout room capability, and a shared folder for uploading sketch photos. For prototype day, confirm which tool the team will use (Figma, Keynote, InVision, HTML) and ensure all team members have licenses and access.
For test day, prepare an interview guide template, a recording setup (screen recording software, consent forms), and a note-taking spreadsheet with columns for each interview question.
Tip: Buy twice as many sticky notes and markers as you think you need. Running out of supplies mid-exercise breaks flow and forces an awkward pause. A $30 over-investment in supplies saves hours of sprint momentum.
Step 6: Recruit User Test Participants
User recruitment must begin during agenda planning, not during the sprint itself. You need five test participants confirmed and scheduled for the final day of the sprint, with at least one backup in case of cancellations. Define a simple screening criteria based on your sprint challenge. If you are designing a new onboarding flow, recruit people who recently signed up for a similar product or who match your target persona.
io. Confirm each participant's time slot, send calendar invitations, and share any necessary logistics (office address, video call link, NDA if required). Build the test schedule into your sprint agenda with specific times for each interview, breaks between sessions, and a team debrief session at the end of the day.
Tip: Recruit six participants and schedule the sixth as a 'backup' slot at the end of the day. At least one person will cancel or no-show. If all six appear, treat the extra interview as bonus data, which is always valuable.
Step 7: Brief All Participants Before the Sprint
Send a pre-sprint briefing document to every participant at least five business days before the sprint begins. This document should include the sprint challenge statement (one sentence describing the business question you are trying to answer), the full day-by-day agenda with start and end times, the list of participants and their roles (Decider, Facilitator, domain experts, designers, engineers), any pre-reading or research they should review, logistics information (room location, parking, lunch plans, or remote tool links), and explicit instructions to clear their calendars for the full sprint duration. Emphasize that partial attendance undermines the entire process. If someone can only attend two of four days, discuss whether they should participate at all or attend only for their Lightning Talk on understand day.
Hold a 30-minute kickoff call with the full team to walk through the agenda and answer questions.
Tip: Ask participants to set an auto-responder on their email for the sprint days. The single biggest threat to sprint productivity is people checking email during exercises. Making this request explicit during the briefing normalizes the behavior.
Step 8: Prepare the Sprint Environment
On the day before the sprint begins, set up the physical or digital workspace. For in-person sprints, arrange the room with a large table in the center, whiteboard or paper-covered walls on at least two sides, and a separate quiet area where people can sketch individually. Post the daily agenda on the wall where everyone can see it. Pre-stage all materials: sticky notes and markers at each seat, dot stickers in a central bowl, timer visible from all positions.
For remote sprints, configure your Miro or FigJam board with labeled frames for each day's exercises, pre-populate any templates, and test the video conferencing setup with screen sharing. Create a shared Slack channel or group chat for asynchronous communication during the sprint. Run a 15-minute tech check with the facilitator to verify all tools work correctly.
Tip: Place a large printed version of the sprint agenda at the entrance of the room. When people walk in each morning, they immediately see the plan for the day. This reduces the facilitator's need to repeat logistical information and keeps the team self-oriented.
Step 9: Build in Reflection and Adjustment Points
Add a 15-minute end-of-day reflection to each day of the sprint agenda. During this time, the facilitator asks three questions: what went well today, what felt rushed or unclear, and what needs to change for tomorrow. This is not a retrospective on the sprint challenge. It is a meta-reflection on the sprint process itself.
Document the answers and adjust the next day's agenda if needed. 0, the facilitator might extend the morning sketching review on day two by 15 minutes and compress a less critical warm-up exercise. Also add a brief 10-minute recap at the start of each morning where the facilitator summarizes the previous day's decisions and outputs. This re-anchors the team and prevents drift between days.
Tip: Never adjust the agenda mid-day unless something is genuinely broken. Constant adjustments undermine confidence in the plan. Make adjustments overnight, announce them at the morning recap, and then hold the revised plan firmly.
Examples
Example: B2B SaaS Startup Running a Classic Five-Day Sprint
A 12-person SaaS startup building project management software wants to redesign their onboarding flow. The sprint team is seven people: CEO (Decider), head of product, two designers, one engineer, one customer success lead, and one marketer. No one on the team has done a formal design sprint before. They have a dedicated conference room available for the full week.
The planner chooses the classic five-day format because the team is new to sprints and needs the full pacing to learn the process. Day one runs from 10am to 5pm: 30 minutes for introductions and ground rules, then three 15-minute Lightning Talks from the customer success lead (top support tickets), the CEO (business goals), and the marketer (funnel drop-off data). The rest of the morning is HMW note generation, affinity mapping, and target selection. After lunch, the team maps the current onboarding journey on the wall.
Day two is devoted to sketching: morning Lightning Demos of five competitor onboarding flows, followed by individual note-taking and Crazy 8s. Afternoon is Solution Sketch creation with a 60-minute quiet working session. Day three starts with the Art Museum review (20 minutes of silent walking), then Speed Critique at 3 minutes per sketch for seven sketches (21 minutes), followed by the Straw Poll and CEO's final decision. The afternoon is spent creating a detailed storyboard for the prototype.
Day four is a full build day in Figma, with the two designers leading and the engineer advising on technical feasibility. Day five has five user test interviews scheduled at 9:30, 10:45, 12:00, 1:45, and 3:00, with the full team observing and taking notes. A 60-minute debrief at 4pm synthesizes patterns. Materials were ordered 10 days before: 500 sticky notes, 10 Sharpies, 200 dot stickers, six rolls of butcher paper, and a Time Timer.
Five test users were recruited from the existing customer waitlist using a three-question screener sent two weeks before the sprint.
Example: Agency Team Running a Design Sprint 2.0 for a Client
A digital product agency is running a design sprint 2.0 for a healthcare client who wants to explore a new patient portal concept. The sprint team is six people: three agency members (facilitator, product strategist, UX designer) and three client members (VP of Digital, clinical lead, IT architect). The VP of Digital is the Decider. Budget constraints limit the engagement to four days, and the clinical lead is only available for two of those days.
0 four-day format to fit the budget. Because the clinical lead is only available Monday and Tuesday, the planner schedules all Lightning Talks and the mapping exercise on Monday morning so the clinical lead's domain expertise is captured before they leave. Monday's agenda runs 9am to 6pm: Lightning Talks from 9-10:30 (clinical lead on patient workflows, IT architect on system constraints, VP on business objectives), HMW and mapping from 10:45 to 12:30, lunch break, then Lightning Demos and individual sketching from 1:30 to 4:30. Solution Sketches are assigned as homework due by 8am Tuesday.
Tuesday runs 9am to 5pm: Art Museum review and voting from 9 to 11 (clinical lead attends for this before departing), Decider's final pick at 11:15, and storyboarding from 11:30 to 3pm. The remaining afternoon is spent on prototype planning and asset collection. Wednesday is a full prototype build day with the UX designer leading in Figma while the product strategist writes copy and the facilitator coordinates with test users. Thursday has five patient-proxy interviews (recruited through the client's patient advisory council three weeks earlier) scheduled from 9am to 3:30pm, with a synthesis debrief from 3:30 to 5pm.
The briefing document was sent eight days before the sprint and included three research reports on patient portal usage that all participants were required to read.
Example: Large Enterprise Running a Remote Three-Day Sprint
A financial services company with team members across New York, London, and Singapore wants to sprint on a new internal compliance tool. The core team is seven people across three time zones. The only overlapping working hours are 9am to 1pm EST (2pm-6pm London, 9pm-1am Singapore). The Decider is the Chief Compliance Officer in London. Management has approved three days for the sprint.
The planner designs a hybrid sync-async agenda that uses the four-hour daily overlap window for synchronous group activities and assigns individual work as async tasks. Day one synchronous session (9am-1pm EST): 30-minute kickoff and introductions, two 15-minute Lightning Talks (pre-recorded and watched async the night before, with live Q&A only), HMW exercise using a Miro board with voting, and collaborative journey mapping. Async homework for afternoon: watch two more pre-recorded Lightning Demos, take individual notes, and complete Crazy 8s sketches photographed and uploaded to the shared Miro board by midnight EST. Day two synchronous session: Art Museum review of uploaded sketches in Miro (20 minutes of silent individual review, then group Speed Critique), dot voting, Decider's pick, and collaborative storyboarding.
Async homework: the Singapore-based designer begins the Figma prototype during their working hours, hands off to the London designer who continues, then the New York designer finishes. This relay approach gives the prototype 15+ hours of build time across a single calendar day. Day three synchronous session: prototype review and polish from 9 to 10am, then three user interviews from 10am to 12:30pm (users recruited from the internal compliance team at other business units), and a 30-minute debrief. The planner sent the pre-sprint briefing 10 days early, conducted individual 15-minute tech checks with each participant to verify Miro and Zoom access, and recruited internal test users through an email to compliance managers two weeks before the sprint.
Example: Small Product Team Adapting a Sprint for a Two-Day Workshop
A four-person product team at a consumer mobile app company wants to use sprint methods to explore a new social feature, but they cannot block more than two days because of an upcoming release deadline. The team consists of the product manager (Decider), one designer, one iOS developer, and one data analyst. They work in the same office.
The planner recognizes that a two-day workshop cannot cover all five sprint phases with full fidelity, so they scope it to understand, sketch, and decide only, deferring prototype and test to the following week. Day one runs 9am to 5pm: a 30-minute challenge framing session using pre-prepared competitive analysis and usage data from the data analyst, a 60-minute mapping exercise on a whiteboard, a 45-minute session of Lightning Demos reviewing four competitor apps (examined live on phones rather than in slides), then individual Crazy 8s and Solution Sketch work after lunch. Each team member completes one three-panel Solution Sketch by 4pm. The final hour is used for an abbreviated Art Museum review where the team silently reviews all four sketches.
Day two runs 9am to 3pm: Heat Map dot voting from 9 to 9:30, Speed Critique from 9:30 to 10:15 (4 sketches at roughly 10 minutes each including discussion), the product manager's decision at 10:30, and a detailed storyboard creation from 10:45 to 1pm. From 1 to 3pm, the team creates a rough prototype plan, assigns prototype tasks, and schedules three user tests for the following Thursday. The planner explicitly documented in the agenda that this is a modified sprint covering only three of five phases, with prototype and test happening the following week. This transparency prevented the team from feeling rushed or expecting a testable prototype by end of day two.
Best Practices
Time-box every activity with visible countdowns and enforce the boundaries. When an exercise runs over its allocated time, the facilitator stops it, captures any unfinished threads on a parking lot board, and moves to the next block. Allowing a single exercise to overrun by 20 minutes cascades into compressed time for downstream activities, and the prototype or testing phases invariably suffer because they sit at the end of the schedule.
Separate divergent and convergent activities within each day. Place idea generation, sketching, and brainstorming in the morning when cognitive energy is highest. Place voting, critiquing, and decision-making in the afternoon. Mixing these modes causes context-switching fatigue and produces lower-quality outputs in both categories.
Schedule Lightning Talk experts in advance and give each speaker a strict 10-15 minute slot with a specific prompt. Vague invitations like 'tell us about the customer' produce rambling presentations that consume an hour. Instead, ask each expert a focused question: 'Walk us through the three most common support tickets related to onboarding and what users say in their own words.' This produces actionable input the team can convert into How Might We notes immediately.
Include buffer time between major activity transitions, even if it is only 10 minutes. Participants need moments to refill water, check urgent messages, and mentally shift gears. Agendas packed edge-to-edge feel efficient on paper but create stress and resentment in practice. The buffer also gives the facilitator time to rearrange materials, post new prompts on the wall, or address a confused participant privately.
Distribute the agenda in at least two formats: a detailed document for reference and a simplified one-page visual overview for daily use. The detailed version includes facilitator notes, materials lists, and timing for each sub-activity. The visual version shows only the day's major blocks with start times. Post the visual version on the wall and keep the detailed version on the facilitator's clipboard.
Confirm user test recruitment at least three days before the sprint starts and again the day before testing. Recruitment is the single highest-risk logistics item because the entire sprint narrative collapses if there are no users to test with on the final day. Having confirmed, scheduled participants with calendar holds and reminder emails reduces no-show rates from roughly 30% to under 10%.
Plan the prototype fidelity level during agenda creation, not on prototype day. If the agenda allocates only 5 hours for prototyping, the team must know in advance whether they are building a clickable Figma prototype, a Keynote slideshow, or a paper prototype with a human acting as the computer. This decision shapes which materials to prepare, which team members lead the build, and how realistic the test day interviews will feel.
Run a dry-run walkthrough of the full agenda with the facilitator and one other team member before the sprint. Walk through each activity verbally, confirm the inputs and outputs, identify any gaps in materials, and rehearse the transitions between exercises. This 60-minute investment catches planning errors that would otherwise surface as confusion during the sprint itself.
Common Mistakes
Compressing the sprint into fewer days without cutting any activities
Correction
0 four-day format, they often try to keep every single exercise from the original format and simply run each one faster. This produces an exhausting schedule where no exercise gets adequate time and participants feel rushed through critical thinking moments. The fix is to explicitly categorize each exercise as core or optional during planning. In a four-day format, you typically drop one round of Lightning Demos, simplify the warm-up exercises, and assign Solution Sketches as overnight homework rather than allocating in-session time.
If your agenda for any single day exceeds 8 hours of active work, you have not cut enough.
Not recruiting test users until prototype day
Correction
This is the most common planning failure and it tends to surface as a panicked scramble on day three or four. ' In reality, you can recruit based on your target persona and sprint challenge, both of which are defined before the sprint begins. The screening criteria do not need to reference the specific prototype. Start recruiting during agenda planning, confirm participants five days before the sprint, and send reminders the day before testing.
If you wait until the sprint is underway, you risk having zero users on test day, which wastes the entire investment.
Treating the agenda as a suggestion rather than a contract
Correction
Some facilitators create an agenda but then allow the team to renegotiate timing throughout the sprint. This typically happens when a senior stakeholder says 'we need more time on this' during the understand phase. The result is that understand and sketch expand to fill three days, leaving only one rushed day for prototyping and testing. The agenda must be treated as a binding contract that only the facilitator can modify, and only during the overnight reflection window.
When someone requests more time during the day, the facilitator acknowledges the request, captures it in the parking lot, and addresses it at the end-of-day reflection. This preserves the integrity of the downstream schedule.
Planning identical agendas for in-person and remote sprints
Correction
Remote sprints require fundamentally different timing. Screen fatigue hits faster than room fatigue, so remote sessions need shorter active blocks (45-50 minutes) with longer breaks (15-20 minutes) compared to in-person sessions (60-90 minute blocks with 10-minute breaks). Remote sprints also need explicit async work windows where participants sketch or think independently with cameras off, then reconvene to share. Copying an in-person agenda into a remote format produces six-hour video calls where attention collapses by hour three.
Redesign the agenda specifically for the remote medium, using async sketching windows and shorter synchronous review sessions.
Failing to brief the Decider on their specific role and decision points
Correction
The Decider is the person with authority to make binding choices during the sprint, typically a product leader or founder. Many agenda planners invite the Decider along with everyone else and assume they understand their role. In practice, Deciders often show up expecting to observe rather than decide, or they attend only intermittently. During the briefing step, have a separate 15-minute conversation with the Decider to explain exactly when they will be asked to make a call (after the Straw Poll on decide day, during the target selection on understand day), what authority those decisions carry, and why their presence at those specific moments is non-negotiable.
Over-customizing the agenda for a first-time sprint team
Correction
Teams running their first sprint sometimes try to innovate on the format by adding custom exercises, removing 'boring' phases like the Art Museum review, or restructuring the order of days. This usually happens because the planner has read about multiple sprint variations and wants to combine the best elements. For first-time teams, run the standard five-day format without modifications. The classic sequence was designed so that each exercise builds specific skills and outputs that feed the next.
Once the team has completed one full sprint and understands the rhythm, they have the context to make informed customizations in future sprints.
Other Skills in This Method
Mapping Problems and Defining the Sprint Challenge on Day 1
How to run the Understand phase by creating a problem map, conducting expert interviews, identifying assumptions, and selecting a focused sprint target for the week.
Conducting User Tests and Synthesizing Feedback on Day 5
How to recruit the right test participants, run five moderated usability interviews in one day, capture observations, and identify patterns that validate or invalidate your sprint hypothesis.
Storyboarding the User Journey for Sprint Prototyping
How to create a step-by-step storyboard that translates the winning sketch into a coherent user flow, serving as the blueprint the team follows during prototype day.
Building a Realistic Prototype in One Day
How to rapidly create a high-fidelity, testable prototype using tools like Figma or Keynote that feels real enough to generate authentic user feedback without writing production code.
Facilitating a Design Sprint as the Sprint Master
How to effectively facilitate each phase of a design sprint, manage group dynamics, enforce timeboxes, and guide teams through structured exercises from start to finish.
Running Design Sprints Remotely with Distributed Teams
How to adapt the design sprint framework for remote or hybrid teams using tools like Miro, FigJam, and Zoom, including async exercises and strategies to maintain energy and engagement.
Sketching Solutions and Running Structured Voting
How to guide participants through Crazy 8s, solution sketching, heat-dot voting, and the Decide phase to converge on the strongest ideas without groupthink.
Frequently Asked Questions
How do I decide between a classic five-day sprint and a design sprint 2.0 four-day format?
Choose the classic five-day format when your team has never run a sprint before, when the problem space is deeply unfamiliar, or when the Decider needs time to observe before committing. Choose the design sprint 2.0 four-day format when your team has completed at least one prior sprint, when participants can handle an intense first day that runs 8-9 hours, and when you need to reduce the calendar commitment by one day. The four-day format is not simply a faster version of the five-day format. It restructures how exercises flow, requires more pre-work from participants, and demands a more experienced facilitator.
How long should planning the sprint agenda take?
Expect 3-5 hours of focused planning work spread across several sessions. The first session (60-90 minutes) covers format selection, stakeholder constraints, and a draft day-by-day outline. The second session (60-90 minutes) fills in specific exercises, durations, and materials. A third session (60 minutes) handles logistics: room booking, supply ordering, user recruitment, and participant briefing. If you are running a remote sprint, add another 60-90 minutes for configuring the digital workspace and running tech checks with participants.
Should I plan the sprint agenda before or after defining the sprint challenge?
You need a preliminary sprint challenge to plan the agenda, but the challenge will be refined on day one of the sprint. During planning, work with the Decider to articulate a one-sentence challenge that scopes the sprint. This challenge determines how many Lightning Talk experts to invite, what screening criteria to use for test users, and whether any phases need extra time. The mapping and defining exercise on day one (see [mapping and defining sprint challenges](/skills/mapping-and-defining-sprint-challenges)) will sharpen this challenge into a specific target, but the initial framing is sufficient for agenda planning.
How do I handle a participant who can only attend part of the sprint?
Determine exactly which activities require their presence and schedule them into those specific blocks. Domain experts who provide Lightning Talks need to attend only the understand phase. Engineers who advise on feasibility are most needed during storyboarding and prototyping. If the partial participant is the Decider, rearrange decision points to fall within their available hours, because the sprint cannot progress without binding decisions. For anyone else, have them join for their relevant sessions, brief them on decisions made in their absence, and accept that their influence on the final direction will be limited.
Why does my sprint agenda keep running over time each day?
The three most common causes are: insufficient buffer time between activities (add 10-15 minutes between major blocks), discussion-heavy exercises that lack explicit time limits (use a visible timer and enforce stops), and Lightning Talks that exceed their allotted duration (brief speakers on their exact time limit and cut them off politely when time expires). A subtler cause is that the facilitator is allowing the team to revisit earlier decisions during later phases. If the team re-debates the target user during sketching day, that is a planning failure. Capture the re-debate impulse on the parking lot and move on.
Can I run a design sprint 2.0 remotely, or does the compressed format only work in person?
0 remotely, but you need to adapt the schedule significantly. The compressed day-one format that works in person (8-9 hours) will cause severe screen fatigue remotely. Instead, split day one into two half-day synchronous sessions with async sketching work between them. Use a digital whiteboard tool like Miro or FigJam with pre-built templates for each exercise so participants can work individually and asynchronously. The total elapsed calendar time may stretch to five days even though active synchronous hours match the four-day in-person format. See [running remote design sprints](/skills/running-remote-design-sprints) for detailed remote facilitation guidance.
What is the minimum viable sprint if I only have two days?
In two days, you can cover understand, sketch, and decide, producing a storyboarded concept ready for prototyping. You cannot realistically build and test a prototype in two days unless the prototype is extremely low fidelity (paper sketches or a three-screen clickthrough). Schedule prototype building and user testing for the following week as separate focused sessions. Be explicit with your team that this is a modified sprint, not a compressed full sprint. Trying to cram all five phases into two days produces shallow outputs at every phase and defeats the purpose of the structured process.