How to Run a Sprint
When You Have No Product Team
Sprints aren’t just for engineering teams. A two-week sprint discipline applied to any part of a lean startup — sales, content, ops, hiring — creates focus and velocity that ad-hoc work never does. Here’s the lightweight version that actually works solo or with a tiny team.
- Why sprints work even without a product team
- The 2-week sprint structure for a lean team
- Sprint planning — choosing the right goal
- The daily check-in that takes 5 minutes
- The sprint review — what to actually review
- Handling the scope creep that kills sprints
- Using AI to run your sprint more effectively
Why Sprints Work Even Without a Product Team
The value of a sprint isn’t the methodology — it’s the commitment structure. When you define a specific goal for two weeks and nothing else, you eliminate the daily decision-making cost of “what should I work on today?” That decision overhead is enormous in early-stage companies where everything feels equally urgent.
Sprints also create natural forcing functions. A two-week deadline on a specific goal makes you confront scope earlier, say no more, and ship something rather than perfect something indefinitely.
The sprint goal should be specific enough that at the end of two weeks, everyone can answer “did we achieve it?” with a clear yes or no. “Improve sales” is not a sprint goal. “Sign 3 new pilots by [date]” is a sprint goal.
The 2-Week Sprint Structure for a Lean Team
Day 1 (Monday): Sprint planning — 60 minutes. Set the goal, break it into tasks, assign owners.
Days 2-9: Execution — daily async check-in, weekly sync if needed.
Day 10 (Friday): Sprint review — 30 minutes. Did we hit the goal? What do we carry forward? What do we drop?
That’s it. No ceremonies, no velocity tracking, no burndown charts. Three events over two weeks — planning, execution, review.
Sprint Planning — Choosing the Right Goal
The most common sprint planning failure: choosing a goal that’s actually three goals, or choosing a goal that can’t be evaluated as done-or-not-done at the end of two weeks.
A good sprint goal has a specific metric, a specific deadline, and a clear owner. “Launch the redesigned onboarding flow to all new users by Friday the 14th” is a good sprint goal. “Improve onboarding” is not.
Before finalising the goal, ask: what are we explicitly not doing this sprint so we can do this? That’s the other half of planning — the decision about what to defer is as important as the decision about what to prioritise.
“I need to plan a 2-week sprint for my [describe team size and function]. My highest priority right now is [describe the broad area]. Help me: (1) Write a specific, measurable sprint goal that could be clearly achieved or not achieved in 2 weeks, (2) Break it into 5-8 specific tasks with rough time estimates, (3) Identify 2-3 things we should explicitly defer or say no to this sprint in order to protect focus, (4) Flag any risks or dependencies I should surface before the sprint starts.”
The Daily Check-In That Takes 5 Minutes
A daily standup that’s actually a standup — not a meeting with chairs — covers three things: what did I do yesterday, what am I doing today, what’s blocking me. Written async, posted in Slack or Notion by 9am. Responses to blockers within 2 hours.
For solo founders: write this for yourself anyway. It takes 3 minutes and forces you to notice when you’ve drifted from the sprint goal — the most common sprint failure mode.
The Sprint Review — What to Actually Review
The sprint review is not a status update. It’s a retrospective with teeth.
Three questions, in order: Did we hit the sprint goal — yes, no, or partially? If partial or no, what specifically got in the way? What do we do differently in the next sprint based on what we learned?
The third question is the one most teams skip, which is why they have the same sprint problems repeatedly. Take 10 minutes on it every time.
“Here’s what happened in our last 2-week sprint. Sprint goal: [state the goal]. What we completed: [list]. What we didn’t complete: [list]. What interrupted us: [list the interruptions or scope changes]. Run a retrospective: (1) Did we hit the goal — yes, no, partially, and why? (2) What was the biggest factor that helped or hurt? (3) What should we change in how we run the next sprint? (4) Should the unfinished work carry into the next sprint, and if so what needs to change to actually get it done this time?”
Handling the Scope Creep That Kills Sprints
Every sprint gets hit with something unexpected — a customer emergency, a board request, an opportunity that feels too good to defer. The instinct is to absorb it into the sprint.
The discipline: when something new comes in during a sprint, it goes on a list, not into the sprint. At the end of the sprint it gets evaluated properly. If it’s genuinely more important than the current sprint goal, you can break the sprint — but do it explicitly, not by just letting the sprint quietly die around the new priority.
Using AI to Run Your Sprint More Effectively
“It’s the middle of our 2-week sprint. Sprint goal: [state it]. Tasks completed so far: [list]. Tasks remaining: [list]. Time remaining: [X days]. New things that have come up that weren’t planned: [list]. Assess: (1) Are we on track to hit the sprint goal? (2) What’s the single biggest risk to completing it? (3) Should we adjust scope, add resources, or defer anything to protect the goal? (4) How should we handle the unplanned items that came up?”
Get 50 more prompts for ops, productivity, and lean startup execution — free.