What a Sprint Actually Is

A sprint is a fixed time period — usually one or two weeks — during which the team commits to completing a specific set of tasks. At the end, you review what shipped, plan the next sprint, and repeat.

The benefits are simple:

• Predictability: You know what will ship and when
• Focus: The team isn't constantly context-switching to respond to new requests
• Regular checkpoints: Weekly or biweekly reviews create natural moments to adjust direction
• Accountability: Commitments are made and tracked

You don't need elaborate ceremonies to get these benefits. A lightweight sprint process can run in four meetings per sprint.

The Four Meetings You Need

1. Sprint Planning (1–2 hours, start of sprint)

Decide what the team will work on this sprint. Review the prioritized backlog. The team estimates effort for each task (story points or t-shirt sizing). Tasks are pulled into the sprint until the team's capacity is full.

Key output: a committed sprint backlog that everyone understands and agrees to.

2. Daily Standup (15 min, every weekday)

Each person answers: what did I do yesterday, what am I doing today, do I have any blockers? Not a status report — a coordination mechanism. Keep it to 15 minutes.

If it regularly runs long, topics are being discussed that should happen in a separate conversation.

3. Sprint Review / Demo (30–45 min, end of sprint)

The team demonstrates what shipped. Non-technical stakeholders (founder, product team) can attend. This is not a formal meeting — it's a demo. "Here's what we built, here's it working."

This single meeting, done consistently, builds trust between engineering and product faster than any other practice.

4. Retrospective (30–45 min, end of sprint)

The team discusses: what went well, what didn't, what to change. Actionable items should be assigned to specific people for the next sprint.

Retrospectives lose value if the action items are never followed up. If you run a retro and nothing changes, teams learn to not take them seriously.

Setting Up the Backlog

Before your first sprint, you need a prioritized backlog — a ranked list of all the tasks you want to build.

Good backlog items:

• Small enough to be completed in less than 3 days by one engineer
• Clearly defined with acceptance criteria ("the user can do X, the system shows Y")
• Prioritized (what matters most is at the top)

Common backlog management mistakes:

• Too large tasks: "Build the auth system" is not a good task. "Add password reset email flow" is.
• No acceptance criteria: "Improve performance" tells engineers nothing. "Reduce dashboard load time to under 1 second on 3G" is actionable.
• Not groomed regularly: The backlog goes stale if it's not reviewed and reprioritized. Schedule a 30-minute backlog refinement session mid-sprint.

Estimation: Keeping It Simple

Story point estimation (Fibonacci sequence, planning poker) works well for experienced teams who can calibrate their estimates against historical velocity. For a team just starting out, it's often simpler to use t-shirt sizing:

• S: Half a day to a day
• M: 1–3 days
• L: 3–5 days
• XL: More than 5 days (break this down before committing)

A 2-week sprint for a team of 3 engineers has roughly 20–25 engineer-days of capacity (accounting for meetings, code review, and the unexpected). Fit accordingly.

What Your Sprint Board Should Look Like

Keep it simple, especially at the start:

• Backlog: Tasks queued but not in this sprint
• To Do: Committed to this sprint, not started
• In Progress: Being worked on now
• In Review: Code written, pending PR review
• Done: Merged to main and deployed (or ready to deploy)

Linear, Jira, or even a GitHub Projects board all work. The tool matters less than using it consistently.

The Most Important Sprint Habit

Commit to the demo. Every sprint, show working software. Even if only one small thing shipped, show it working.

Teams that skip demos slip into reporting on effort rather than outputs. "We worked on the auth system this sprint" is very different from "Here's the login and password reset flow working end to end." The demo keeps everyone honest about what done actually means.