How We Run Product Sprints (and Why Most Teams Do It Wrong)

The Scrum Tax

Most product teams run Scrum, or something that approximates Scrum. Two-week sprints, daily standups, sprint planning, backlog grooming, sprint review, retrospective. The full ceremony.

On paper, this structure produces coordination, alignment, and predictability. In practice — particularly for small, early-stage product teams — it often produces something else: a permanent overhead of meetings and rituals that consume 15-20% of the team's week without corresponding value.

We've tried many variations. Here's the process we've converged on for teams of 2-6 people, pre-PMF.

The Case Against 2-Week Sprints

Two-week sprints are long. In the time it takes to complete a two-week sprint, you could have shipped and gotten feedback on 4-6 smaller things. Pre-PMF, that feedback is more valuable than the coordination benefit of longer sprints.

Two-week sprints also encourage scope creep. When a sprint is two weeks, stories expand to fill the time. Engineering estimates balloon. "While we're in there" additions appear. The sprint that was supposed to be 8 story points becomes 12, and something gets punted.

One-week sprints solve both problems. They're short enough that scope creep is obvious immediately. They're fast enough that you're getting production feedback every week, not every two weeks. The coordination overhead is similar.

Our Sprint Structure

Monday (1 hour): Sprint kick-off

Not a planning meeting. A kick-off. The difference: planning is where you figure out what to do. Kick-off is where you confirm what you already know you're going to do.

The work of figuring out the sprint's priorities happens before the meeting — asynchronously, by whoever owns the backlog. By Monday morning, the sprint is planned. The kick-off is 30 minutes to review it and one final check: is there anything blocking anyone from starting? Any dependencies that need to be resolved today?

The second 30 minutes: technical alignment. Engineers walk through their approach for any non-trivial tasks. This is not estimation theater — it's ensuring the team has a shared understanding of what they're building before they start building it.

Daily: Async standup

Not a meeting. A Slack update. The format:

• What did I do yesterday?
• What am I doing today?
• Any blockers?

Posted by each team member before 10am in a dedicated channel. The team reads it. Blockers get addressed in threads or short 1:1 conversations.

The async standup preserves the information sharing benefit of a standup without the synchronous cost. For a 5-person team, replacing a 15-minute daily standup with async updates saves 75 minutes per person per week.

Friday (30 minutes): Demo

Every Friday, the team demos what shipped that week. Not a polished presentation — a literal screen share of the thing that was built.

The audience: the founding team plus any adjacent stakeholders. The goal: shared visibility into what actually shipped, and a brief discussion of what it means for next week.

This is the most important ritual in the sprint cycle. It creates a weekly forcing function to ship. Things that don't ship by Friday demo are visible failures.

Every other Friday (30 minutes): Retrospective

Not every sprint. Every two sprints.

One question per person: what's one thing we should change about how we work? The facilitator writes them on a whiteboard or shared doc. The team votes on the one change to make for the next two sprints.

Retrospectives every sprint produce diminishing returns. The improvements from each retro take more than one sprint to evaluate. Every other sprint gives you enough cycles to see if a change is working.

Definition of Done

The single most important process decision in any sprint cycle. Ambiguity about when something is "done" produces partially shipped features, endless review cycles, and sprints that never fully close.

Our definition of done: deployed to production and working for real users.

Not "code complete." Not "merged to main." Not "passed QA on staging." Deployed to production.

This forces real deployment discipline. If the infrastructure can't deploy reliably, it becomes visible immediately. If there are approval steps that block deployment, they need to be addressed. If QA on staging takes longer than a sprint, the QA process needs to change.

The only legitimate exception: features with complex launch sequencing (behind a feature flag, coordinated with marketing). For these, "done" is "feature flag ready, confirmed working on staging, launch date set."

Velocity Without Story Points

Story points are estimation theater. The most common use of story points is to fill planning meetings with debates about whether a task is a 5 or an 8, and to produce velocity metrics that teams optimize for rather than using as honest signals.

We track velocity as: number of features shipped per sprint. A feature is a user-facing change that provides value. Bug fixes count half.

This metric is coarser than story points but more honest. It doesn't reward gaming, doesn't require estimation debates, and directly measures what actually matters: are we shipping things?

Use it as a trend metric. If you're shipping 3-4 features per sprint consistently and you drop to 1-2, something is wrong. That's a conversation worth having.

When to Add Ceremony

The lean approach described above works well for teams of 2-6 people, pre-PMF. As teams grow and products mature, some ceremony becomes genuinely valuable:

• More structured sprint planning when there are multiple competing priorities across more than one team
• Formal retrospectives every sprint when the team size makes information flow less reliable
• Story points when you have multiple teams whose work needs to be coordinated around a shared capacity model
• QA process when the product has enough complexity that ad-hoc testing misses things at an unacceptable rate

Add ceremony when you have a concrete problem it solves, not when you feel like a "real" product team should have it. Every ritual you add should have a specific failure mode it prevents.

The goal is velocity. Process serves velocity; it doesn't substitute for it.