What a sprint actually is (stripped of the jargon)
A sprint is a fixed time period — usually two weeks — during which the team commits to completing a specific set of tasks. At the end, you ship something. Then you do it again.
The value of a sprint isn't the ceremony around it. It's the rhythm: a predictable cycle of plan → build → ship → review. Without this rhythm, small teams drift — reacting to whatever's loudest rather than building towards a goal.
The minimal sprint process for 2–8 engineers
Monday morning: Sprint kickoff (45 minutes)
The entire team joins (or joins a video call if remote). You do four things:
- Review last sprint — what did you commit to? What shipped? What didn't? (5 min)
- Pick the sprint goal — one sentence: "This sprint we will ship X and fix Y." (5 min)
- Select issues — pull from the backlog, assign to engineers. Be realistic about capacity. (25 min)
- Confirm blockers — is anything preventing us from starting any of these issues right now? (10 min)
That's the entire planning meeting. 45 minutes, then everyone goes back to building.
Every morning: Async standup (5 minutes per person)
Each engineer posts in Slack/WhatsApp before 10am:
- Done yesterday
- Doing today
- Blocked on anything?
The team lead reads these and follows up on blockers. No live standup call required for small teams — the async version is faster and less disruptive.
Friday afternoon: Sprint close (30 minutes)
Demo what shipped (even internally), mark issues as done, and do a quick retrospective:
- What went well this sprint?
- What slowed us down?
- One thing to change next sprint
💡 The retrospective rule: One actionable change per sprint, maximum. Teams that try to fix five things at once fix none of them.
Track your sprints in Resolvo issue tracker
Create sprints, assign issues, track progress. Free for small teams.
Try Resolvo Free →How to fill a sprint without overcommitting
The most common sprint failure is overcommitment — the team picks 20 issues and ships 8. After three sprints of this, planning becomes meaningless because nobody believes the sprint is a real commitment.
The fix: track your velocity. After your first 3 sprints, you'll know roughly how many issues your team completes per sprint. Use that number as your cap — never pick more than your average velocity, plus 10%.
A typical 3-person startup team completes 8–15 issues per two-week sprint depending on issue complexity. Start conservative.
Issue sizing for small teams
Forget story points. Use T-shirt sizing: Small (half a day), Medium (1–2 days), Large (3–5 days). If an issue is larger than Large, break it down before putting it in the sprint.
The goal isn't precision — it's sanity. If you can't fit 8 medium issues and 4 smalls into two weeks, your sprint is overloaded. Simple as that.
When to break the sprint
Small teams get interrupted. A production bug requires immediate attention. A customer escalation demands engineering support. A founder's priority shifts. Sprints need to be flexible:
- Critical bugs — drop into sprint immediately, drop lowest-priority issue to compensate
- New founder priority mid-sprint — have a brief conversation: which committed issue gets dropped to make room? No free additions.
- Underestimated issues — if an issue balloons from Medium to Large mid-sprint, flag it immediately, don't silently let it eat the sprint
What a sprint board looks like
Keep it simple: four columns.
- Backlog — issues ready to pick up but not yet in sprint
- This Sprint — committed for this two weeks
- In Progress — actively being worked on
- Done — shipped and verified
Resolvo's issue tracker supports this exact view with sprint grouping and drag-and-drop status updates.
Run sprints without the enterprise overhead
Resolvo issue tracker: sprints, backlogs, assignments. Free for small teams.
Start Free →