Why Sprint Planning Is Wrong for One Person

Sprints Work. Just Not for a Team of One.

Scrum sprints are one of the most successful project management innovations of the last thirty years. They've helped thousands of software teams ship better products, more predictably, with fewer catastrophic failures along the way. The Scrum Guide explicitly describes Scrum as a framework for teams of developers working together on complex products. Sprint planning exists because a group of humans needs a shared commitment cycle.

But when you're a solo developer, there's nobody to align with. Sprint planning for one person is a coordination ceremony with no one to coordinate. You're holding a meeting with yourself, estimating your own capacity in story points, assigning tickets to yourself, and then running a sprint review where you present your work to an empty room. That's not process. That's theater.

Understanding why sprint planning doesn't work solo developer workflows is the first step toward finding something that actually helps you ship.

How Sprint Planning Is Supposed to Work

I want to be fair to Scrum before I tear into it. Sprint planning is a well-designed ceremony that solves real problems.

A sprint is a fixed timebox, usually two weeks, during which a team commits to delivering a set of work items. The sprint starts with sprint planning: a meeting where the product owner presents prioritized backlog items and the development team discusses which ones they can realistically complete within the timebox.

The team estimates effort using story points. Story points are intentionally abstract. They don't map directly to hours. A 8-point story for Developer A might take 3 days, while the same 8-point story for Developer B might take 5 days. That's fine, because story points measure relative complexity, not duration. The team's velocity (how many points they complete per sprint, on average) tells the product owner how much work to expect in future sprints.

During the sprint, the team holds daily standups. Each person says what they did yesterday, what they're doing today, and whether anything is blocking them. The standup exists to surface blockers fast, before they derail the sprint.

At the end of the sprint, there's a sprint review. The team demonstrates completed work to stakeholders. Then there's a sprint retrospective, where the team discusses what went well, what didn't, and what to change for the next sprint.

Every piece of this system assumes multiple participants with different knowledge and different roles. This matters. If you're going to apply sprints for solo developer work, you need to understand that you're not just borrowing a scheduling technique. You're adopting a coordination framework. And coordination without multiple parties is just paperwork.

The Overhead Tax of Running Sprints Alone

Every sprint cycle comes with built-in overhead:

• Sprint Planning: 1-2 hours to plan two weeks of work
• Backlog Grooming: 30-60 minutes to review and prioritize
• Daily Standups: 15 minutes per day (even with yourself)
• Sprint Review: 30-60 minutes to demo completed work
• Sprint Retrospective: 30-60 minutes to reflect on what went well

For a team of eight, this overhead pays for itself. Coordination saves more time than the ceremonies cost. For a solo developer, it's pure waste.

A two-week sprint cycle burns roughly 5-7 hours on ceremonies. For a side project builder working nights and weekends with 10-15 hours available, that's 30-40% of total coding time consumed by process overhead. Not building. Not shipping. Process.

Why It Breaks Down for Solo Developers

Now let's get into the specific ways sprint planning solo developer workflows fall apart. These aren't edge cases. They're structural problems.

Sprint planning assumes team capacity estimation

Sprint planning's purpose is to answer the question: "Given this team's capacity, what can we commit to delivering in two weeks?" The question only makes sense when "capacity" is a variable worth discussing.

On a team, capacity is complicated. Alice is out Thursday and Friday. Bob just got pulled into a production incident. The new hire is still ramping up. Sprint planning forces the team to account for all of this and produce a realistic commitment.

When you're one person, your capacity is just your calendar. You know how much time you have. You don't need a ceremony to figure it out. The sprint planning solo developer meeting devolves into staring at your backlog, guessing how much you can do, and writing that guess down. Then two weeks later you compare the guess to reality. This is just a journal entry with extra structure.

Two-week sprints create artificial urgency on wrong timescales

The two-week sprint assumes roughly 80 hours of development capacity. A 10-person team has 800 person-hours per sprint. Even a 4-person team has 320.

You, working on a side project after your day job? You might have 10 actual hours across those two weeks. Maybe 15 if you sacrifice some sleep. The sprint timebox was designed for full-time development teams. Applying it to nights-and-weekends work is like using a highway speed limit on a bike path.

What happens in practice: you plan a sprint with 5 items. By the end of two weeks, you've completed 1.5 of them. So you do sprint planning again, carry over 3.5 items, and add one new thing you thought of. Your velocity is low, your carryover rate is high, and the process is generating data that tells you what you already know.

The artificial urgency of a two-week deadline also messes with your priorities. A side project doesn't move in two-week increments. It moves in project-level phases: validate the idea, scope the MVP, build the core, build the UI, test, ship. Some phases take a week. Some take six weeks. Chopping them into arbitrary two-week blocks adds accounting overhead without changing what you work on.

I once tried running two-week sprints on a side project. By sprint 4, I was spending more time grooming the backlog and doing sprint planning than I was actually writing code. The process consumed a measurable percentage of my already-limited development time. That's when I realized this is why sprint planning doesn't work solo developer projects.

Sprint reviews with no audience

The sprint review is supposed to create accountability. You show your work to stakeholders. They give feedback. This feedback shapes what goes into the next sprint.

Picture running a sprint review by yourself. You open your project. You look at what you built. You nod. Meeting over.

There's no feedback because there's no audience. There's no course correction because there's no external perspective. Some people try to solve this by showing their work to friends or posting updates on Twitter. That's fine, but it's not a sprint review. It's just showing your work to people. You don't need Scrum for that.

Story points are meaningless alone

Story points exist for relative estimation across team members. A 3-pointer means "about this hard for our team, given our collective skills and knowledge." The abstraction is intentional. If one developer thinks a task takes 2 hours and another thinks it takes 8, the story point lets them agree on relative effort without arguing about hours.

When you're the only estimator, relative to what? You're comparing the task to yourself. You don't need an abstraction layer between your brain and your estimate. You know how long things take you. A scrum solo developer who assigns story points to tasks is adding a translation step between their intuition and their plan, and that translation step adds no information.

If you want to estimate, estimate in hours. Or better yet, don't estimate at all. Timebox instead. "I'm spending 3 hours on this tonight, and whatever state it's in when I stop is where it is." That's honest. That's useful. Story points for one person are neither.

Sprints don't map to solo project lifecycles

A team running Scrum might operate for years, continuously delivering features across dozens or hundreds of sprints. The sprint is a heartbeat. It never stops.

Your side project has a different shape entirely. It has a beginning, a middle, and an end. You have an idea. You validate it. You scope an MVP. You build it. You ship it. Done. That might take 4 weeks or 12 weeks, but it has a finite arc.

Trying to decompose that arc into sprints is like trying to measure a road trip in laps. Your project isn't 6 sprints long. Your project is "build auth, then build the dashboard, then build billing, then ship." Those milestones are the natural units of progress, and they don't care about two-week boundaries.

What to Do Instead

Project-level milestones with weekly check-ins. That's it. No points, no velocity, no ceremonies.

Here's what that looks like. You start a project. You define milestones that represent real progress:

• Week 1-2: Auth works. Users can sign up, log in, and reset their password.
• Week 3: Dashboard is functional. Users can see their data.
• Week 4: Billing works. Users can pay.
• Week 5: Polish and ship.

Each milestone is a working capability, not a pile of story points. You either have auth or you don't. There's no "auth is 60% done." Auth works or it doesn't. Binary.

At the end of each week, you do a check-in with yourself. Not a ceremony. Just 10 minutes of honest assessment. Are you on track? If not, what's blocking you? Do you need to cut scope? That's your entire "agile" process. It takes 10 minutes a week instead of the hours per sprint that Scrum demands.

The weekly check-in works because it's tied to your actual schedule. You work on weeknights and weekends. A week is a natural unit of time that aligns with how you live. Two-week sprints don't respect your calendar. Weeks do.

If you miss a milestone, you make a real decision: cut scope or push the timeline. "Auth was supposed to be done by end of week 2, but I still need to build password reset. I'll push the dashboard to week 4 and push shipping to week 6." That's a meaningful decision about a real project, not adjusting story point estimates on a velocity chart.

FoundStep was built around project-level milestones for exactly this reason. The workflow maps to how solo developers actually build things: scope, milestone, build, check, ship. There are no sprint ceremonies because there's no team to run them for.

You can also read about how to ship faster as a solo developer for more on this approach. The core idea is the same: less process, more building, with just enough structure to know when you're off track.

When Sprints Still Work Solo

I'm not going to pretend there's never a reason for a solo developer to use sprints. There's one scenario where it works well.

If you're a freelancer doing client work with regular delivery cycles, sprints make sense. Your client expects a demo every two weeks. The sprint review actually has an audience (the client), and the cadence creates real accountability. In this case, you're not really solo. You have a stakeholder who provides feedback and influences priority.

What doesn't work is running sprints on a pre-launch side project with no stakeholders, no team, and 10 hours a week of development time. That's the context where overhead swallows the value. That's where team tools like Jira and Linear add friction instead of removing it.

The Ceremony Trap

There's something seductive about Scrum ceremonies for solo developers. Running sprint planning feels productive. Estimating stories feels productive. Maintaining a velocity chart feels productive. You're doing all the things that "real" development teams do, and it makes your side project feel legitimate. Professional. Serious.

But it's a trap. The ceremonies exist to solve coordination problems, and you don't have coordination problems. What you have is a shipping problem. You need to get from idea to product as fast as possible with your limited time. Every minute you spend on process is a minute you didn't spend building.

I fell into this trap myself. I had a beautiful Jira board with epics, stories, sub-tasks, story points, sprint goals, and a burndown chart. My project management setup was impeccable. My project was six months old with no shipped product. I was managing, but I wasn't building.

The day I deleted the board, wrote down 6 things my app needed to do, and started working through the list linearly was the day the project started moving. I shipped within 5 weeks. The process overhead had been eating 20-30% of my limited development time, and I hadn't noticed because the overhead felt like work.

If you recognize yourself in this, you're not bad at Scrum. Scrum is bad for your situation. That's an important distinction. A scrum solo developer isn't failing at the methodology. The methodology is failing the developer.

Frequently Asked Questions

Can you do sprints as a solo developer?

Technically, nothing stops you. You can create a board, write stories, estimate in points, run two-week sprints, and do reviews and retros by yourself. But you're performing team coordination ceremonies with no team. Every ceremony assumes multiple participants, and each one costs time without providing the coordination value it was designed for. The overhead costs more than the structure provides. Use project-level milestones with weekly check-ins instead.

Is agile methodology useful for one person?

Some agile principles work perfectly well when doing agile for one person. Iterating quickly, shipping small increments, getting user feedback early, responding to change over following a plan. These are just good engineering practices regardless of team size. But the agile ceremonies (daily standups, sprint planning, sprint reviews, retrospectives) are coordination tools. They exist to synchronize multiple people. When you apply agile for one person, keep the principles and drop the ceremonies.

What should solo developers use instead of sprints?

Project-level milestones with weekly check-ins. Define your milestones based on working capabilities: "auth works," "dashboard is functional," "billing is integrated," "it ships." Each milestone is binary. Done or not done. At the end of each week, spend 10 minutes asking yourself: am I on track? If not, cut scope or push the timeline. No points, no velocity charts, no burndown charts. Just a clear map from where you are to where "shipped" is.

Are story points useful for one person?

No. Story points exist for relative sizing across team members with different skill levels and working speeds. When you're the only estimator and the only builder, the abstraction adds nothing. Just estimate in hours if you want to estimate at all. Better yet, timebox: "I'm spending tonight on this feature, and wherever it is when I stop is where it is." Timeboxing is honest in a way that story points for one person never are.

Three things to do right now:

1. Stop running sprint ceremonies with yourself. Delete the sprint board.
2. Take your current project and define the minimum scope needed to ship.
3. Lock that scope. Build it. Ship it.

---

You don't need sprint planning. You need a finish line. Drop the ceremonies, set your milestones, and actually ship. Get started with FoundStep and build your project with a workflow that was made for one person.