I ran "proper" sprint planning by myself for six weeks.
Monday planning session at 9am. Me, my backlog, a Notion board with swim lanes. Thursday retrospective. Me, my notes, and a growing sense of absurdity. I did the Daily Scrum for exactly one day before deciding that narrating your progress to an empty room is not the productivity hack anyone described.
The problem wasn't discipline. It was that I was running a ceremony designed for teams of 3-9 people as a party of one. Agile sprint planning doesn't scale down to a solo developer. It breaks. Building a lighter version of the same ceremony doesn't fix it. You need something structured around being alone from the start.
Here's the solo sprint planning system I actually use. It runs in about 30-45 minutes at the start of every two-week cycle. It's the main reason I went from three abandoned side projects to shipping FoundStep.
Why Scrum Sprint Planning Breaks for Solo Developers
The Scrum Guide specifies that a Scrum team needs "one Scrum Master, one Product Owner, and Developers." A sprint planning meeting exists as a negotiation between these roles. The Product Owner prioritizes what should get built. The developers push back on how much they can actually do. The Scrum Master keeps things from derailing.
That friction is the point. The sprint commitment comes from pressure between people with competing incentives.
When you're building alone, you play all three roles in the same planning session. The Product Owner in you wants to ship everything. The developer in you knows how long things actually take. And neither of them has anyone to referee. The negotiation becomes a monologue, and monologues rarely say "no" to themselves.
The result is what I'd call the solo dev planning trap. Either you over-commit (the Product Owner in you crushed the developer's objections) and ship late, or you under-commit (you listed vague tasks with no real goal) and don't really ship at all. Six weeks of that loop and I stopped doing "sprint planning" entirely.
| Team Scrum | Solo Sprint System | |
|---|---|---|
| Who sets the goal | Product Owner, with developer input | You (Step 1, in writing) |
| Who pushes back on scope | Developers vs. Product Owner | Your Step 3 "necessary?" filter |
| Who protects the backlog | Scrum Master enforces it | Your written scope lock (Step 4) |
| How commitment is made | Group agreement in planning meeting | Solo written commitment |
| How progress is reviewed | Sprint Review + Retrospective with the team | 10-minute end-of-sprint self-check |
The 5-Step Solo Sprint Planning System
The system I settled on replaces Scrum's role-based negotiation with a series of explicit gates — decisions you force yourself to make before you start building. It takes 30-45 minutes at the start of each sprint. The rest of the sprint, you build without touching the plan.
Before you run this, you need a clear product roadmap — a written commitment to what you're building, in what order, and what you're not building yet. If you don't have one, build your product roadmap first. Sprint planning is execution discipline; the roadmap is the strategy it operates on.
Step 1. Set ONE sprint goal (not a list)
Write one sentence. "By the end of this sprint, [specific user-facing outcome]."
Not "work on the auth flow." Not "improve performance and add dashboard." A specific thing that either happened or didn't — something like "Users can sign up, log in, and create their first project without hitting an error."
If you can't write that sentence in two minutes, the goal isn't clear enough to plan against. Stop and figure out what you're actually trying to accomplish before you do anything else.
One goal forces a choice. A list of goals lets you feel productive while building the wrong thing.
Step 2. Validate feasibility before you commit
Look at your actual calendar for the next two weeks. Not idealized. Real. Count the hours you genuinely have for focused building. Then multiply that number by 0.6.
That 40% disappears into context switching, debugging rabbit holes, the deployment issue you spend three hours fixing on a Sunday, the package that breaks after an upgrade. If you've been writing code for more than six months, you know exactly what I'm describing.
Can you reach the sprint goal in those buffered hours? If not, either shrink the goal or extend the sprint. Don't just start and hope.
Step 3. Cut your feature list down
List the features that deliver the sprint goal. Not everything in your backlog. Not the nice-to-haves you've been eyeing. The minimum set that gets you to the outcome in your sprint goal sentence.
Ask this about each feature: is this actually necessary to reach the goal? If the honest answer is "probably not, but it would be a nice improvement," move it to a separate "next sprint" list and stop looking at it. That list exists so the idea isn't lost — not so it can sneak back in mid-sprint.
Step 4. Lock the scope (the step most solo devs skip)
Read the feature list one more time. Then close the doc and commit. This is what you're building, and you're not adding to it.
The Agile Alliance describes protecting the sprint backlog from changes as a core principle. In Scrum, the Scrum Master enforces this boundary. Solo, the only protection is your own written commitment — made explicit and held to when something tempting shows up. FoundStep's scope locking feature builds this constraint directly into the workflow so your willpower isn't the only line of defense.
My track record here is simple. Every time I've broken this rule, I've regretted it. Not sometimes. Every time. The "let me just add this one small feature" never stays small. It needs another component. That component reveals an edge case. The edge case takes an afternoon. The original goal ships late or half-finished.
The scope lock isn't bureaucracy. It's what makes the sprint real.
Step 5. Ship at the end, not "mostly done"
At the end of the sprint, sit down for ten minutes and answer three questions:
- Did I ship what I committed to? (Yes or no, not "mostly.")
- What slowed me down that I could prevent next sprint?
- What's one thing I'll do differently?
That's the retrospective. No sticky notes, no frameworks, no 90-minute ceremony. But answer honestly, especially question 1. "Mostly done" is not done. If you treat it as done, you'll never accurately scope the next sprint and you'll never build a real shipping rhythm.
That honesty is the point.
How Long Should a Solo Sprint Be?
Start with two weeks.
Most Scrum teams use two-week sprints because it's long enough to build something meaningful and short enough to catch a wrong turn before it costs a month. Agile sprint planning literature recommends this two-week rhythm for a reason — the feedback loop tightens without the overhead becoming the work. The same logic holds solo, and if anything, working alone means you need that loop faster, not slower.
I made the mistake of trying one-week sprints early on. They sound efficient. In practice, solo developers spend roughly 30% of their time on things that aren't building — debugging environment issues, researching implementations, handling infrastructure, reading documentation. One week doesn't leave enough build time after that overhead.
Two weeks is the default. Three weeks works if you're building large, complex features for an established product. Don't go past three. Beyond that, the cycle loses urgency and you're back to "let's see how it goes" territory.
Tools for Solo Sprint Planning
The common advice is Jira. Don't use Jira.
Jira was built for teams running Scrum with Scrum Masters managing boards and ceremonies. For a solo developer, it's ten times the interface you need and ten times slower than a plain document. Every hour spent managing a Jira board is an hour not building. If you're already convinced, the Jira alternative for solo developers comparison explains why in detail.
The best sprint planning tools for solo work have low friction and open fast:
A plain Notion page or Obsidian note with the sprint goal at the top, the feature list below it, and checkboxes is enough for most solo projects. The goal is something you'll open at the start of each sprint and at the end, not something that impresses anyone.
If you want a bit more structure without the ceremony, Linear works well. It's built for developers, not process managers.
I use FoundStep now. It's built for solo developer workflows and bakes both the validation step and the scope-locking step into the workflow directly. The discipline is in the tool, not just in your willpower — which turns out to matter a lot.
Pick something with low friction and actually open it at the start of each sprint. That's the whole trick.
The Solo Sprint Planning Template and Checklist
Run this at the start of every sprint. Total time: 30-45 minutes. This sprint planning template covers both phases — setup and review.
Sprint Setup (start of sprint)
- Write ONE sprint goal in one sentence (specific outcome, not an activity)
- Check your real calendar and count actual available hours for the next 2 weeks
- Multiply available hours by 0.6 to get realistic output hours
- List the minimum features that deliver the sprint goal
- Remove anything that doesn't pass the "necessary for the goal?" test
- Write the final feature list somewhere visible
- Commit. This scope is locked until the sprint ends.
Sprint Review (end of sprint, 10 minutes)
- Did I ship what I committed to? (yes/no, "mostly" counts as no)
- What slowed me down?
- What will I do differently next sprint?
Frequently Asked Questions
Can you do Scrum by yourself?
Technically, no. The Scrum Guide specifies that Scrum requires a Scrum Master, a Product Owner, and developers. It's a team framework built around role-based negotiation. You can't really have that negotiation with yourself.
What you can do is work with the same idea — time-boxed cycles, a defined goal, locked scope. That's what the 5-step system above implements. It's not Scrum. It's the same core concept, rebuilt for one.
How many story points should a solo sprint have?
Skip story points entirely. They exist to calibrate velocity across team members with different experience levels and working styles. Solo, you have exactly one velocity — yours. And you don't need points to compare it against anyone.
Use hours instead. Estimate each feature in rough hours, total them, compare against your Step 2 output hours. That's the only math you need.
What happens if I don't finish my sprint?
Carry the unfinished work into the next sprint goal. But first answer the retrospective question honestly: why didn't you finish?
If the answer is over-scoping, tighten Step 3 next time. If something unexpected derailed you, adjust the multiplier down to 0.5 — your workflow might need more buffer. If the scope lock broke mid-sprint, write down what pulled you off track and treat it as a pattern to eliminate.
Don't carry unfinished work forward and add the new sprint's scope on top. That's how sprints collapse into an endless backlog of half-finished things.
Start Your Next Sprint Right
The ceremonies Scrum built for teams don't survive contact with solo development. The discipline does.
Set one goal. Check your actual capacity. Pick the minimum features. Lock the scope. Ship.
Five steps, 30-45 minutes, every two weeks. I'm still refining mine, honestly. But it turned three dead repos into something I actually shipped — which is the test that matters.
If you want a tool that builds this discipline into the workflow itself, try FoundStep. It's what I built specifically for solo developers who need the planning layer, not just the building layer.
