For a long stretch, Scrumpy's own backlog was run by exactly one person: me. It taught me something I did not expect to write on a scrum company's blog, which is that most of scrum is useless when you work alone, and the small part that is left is worth more than ever.
That is not a dig at scrum. It is what the framework is for. Nearly everything in it, the sprint commitment, the daily standup, planning poker, the review, exists to keep a group of people pointed the same way. Alone, there is no group. So the honest question for a solo developer is not "how do I do scrum properly," it is "which pieces of this actually help one person, and which am I doing because a book told me to."
Scrum is mostly a communication protocol
Strip scrum down and most of it is a way for people to agree on things without stepping on each other. Standup exists so three developers do not discover at 5pm they built the same thing. Planning exists so a team commits to one shared goal. Estimation-by-committee exists so the group's guesses average out. The retrospective exists so a team can air friction it cannot raise in the moment.
Every one of those assumes an "us." Take away the other people and the protocol has nothing to coordinate. You do not need a standup to tell yourself what you did yesterday. You already know. You were there.
The two pieces worth keeping
What survives is not the meetings. It is the artifacts underneath them, and they matter more solo, not less, because there is no team to catch your mistakes.
- One ordered backlog. The single most valuable habit for a solo developer is keeping a single list of what to do next, in priority order. Working alone, the constant pull is to do the most recent thing, the bug that just annoyed you, the idea from ten minutes ago, instead of the most important thing. An ordered list is the cheap fix. It decides once, calmly, so you do not re-decide anxiously all day.
- A visible board. The other trap of solo work is starting five things and finishing none, because nobody is watching and nothing forces a thing to reach done. A board you can see, with your work moving left to right, makes that visible to the one person who needs to see it. Even a three-column to-do, doing, done is enough.
That is the whole kit. A list and a board. If you keep those two and drop the rest, you have taken the part of scrum that helps you and left the part that was addressed to a team.
Skip the sprints, keep the flow
This is where I will part with the orthodoxy plainly: most solo developers should not run sprints. A sprint is a shared, time-boxed commitment, and the ceremony around it, plan it, protect its scope, review it, only pays off when a group is committing together. On your own it is mostly overhead you impose on yourself.
What fits better is a continuous board where you pull the next item when you are ready and there is no fortnightly boundary to plan around. This is the difference between scrum and kanban in miniature, and for one person the kanban side usually wins. It is exactly why Scrumpy lets you switch sprints off entirely: the board becomes a simple always-on kanban, the sprint planning and estimation machinery disappears, and you are left with an ordered backlog flowing into done. For a team of one, that is the right shape out of the box.
If you genuinely focus better with a deadline, keep a loose personal rhythm, a rough weekly target, say, but hold it lightly and skip the formal planning and review it would carry for a team.
What about estimation?
Story points are a team's shared language for relative size, agreed out loud so no single voice dominates. Alone, there is no one to agree with, and points mostly become a number you argue with yourself. I do not bother with them solo.
The one habit worth keeping from estimation is the instinct behind it: noticing when a task is too big. If something feels like it will take days and touch everything, that is still the signal it always was, that the work is hiding several smaller pieces, and it is worth splitting before you start, whether or not you ever put a number on it.
Keep it light, and let it grow
The reason to run this lean is not laziness, it is that a heavy process with no one to serve becomes a chore you eventually abandon, taking the useful list-and-board habit down with it. Keep it small enough that you actually maintain it.
The nice thing about starting light is that it scales when you do. The day a second person joins, or a client wants to watch progress without you emailing screenshots, the board is already there, and in Scrumpy an extra viewer costs nothing since view-only seats are free. If that second person turns into a real team, you flip sprints back on and the framework is waiting. Until then, do less. On your own, an honest list and a board you actually look at will carry you further than any ceremony you perform for an audience of one.
Frequently asked questions
Do solo developers need scrum?
Not the full framework. Most of scrum is a protocol for keeping several people in sync, and on your own there is nobody to sync with. What is worth keeping is the artifacts rather than the ceremonies: an ordered backlog and a visible board. The meetings, roles and formal estimation add overhead without adding much for a team of one.
What scrum practices are worth keeping for a solo developer?
Two things carry their weight alone. First, a single ordered list of what to do next, so you always work on the most important thing instead of the most recent thing. Second, a board that makes your work-in-progress visible, which stops you starting five things and finishing none. Nearly everything else in scrum exists to coordinate people you do not have.
Should a solo developer run sprints?
Usually no. Sprints exist to commit a team to a shared, time-boxed goal, and alone the ceremony outweighs the benefit. A continuous board where you pull the next item when you are ready tends to fit solo work better. If you do want the rhythm of a deadline to stay focused, a light personal cadence can help, but skip the formal planning and review.
Is a kanban board better than scrum for one person?
For most solo developers, yes. A simple always-on board, where work flows from to-do to done without sprint boundaries, matches how one person actually works. You keep the ordered backlog and the visible flow and drop the sprint machinery, which is the part that mainly serves a group.
