Scrum for startups and solo builders

A founder builds a product alone, deciding every morning what to do. There is a customer to find, a feature to finish and a bug that has been open for three weeks. Scrum seems like the wrong tool: it is a framework for teams, and she is one person. Yet she faces the problem it addresses, deciding what to build under uncertainty with limited time, and the main ideas travel better than the full ritual.

What the Guide asks of a team

The Guide says the fundamental unit of Scrum is a small team of people, consisting of one Scrum Master, one Product Owner and Developers. The Scrum Team is small enough to remain nimble, typically ten or fewer. The Guide also describes the framework as purposefully incomplete, built on the collective intelligence of the people using it, and states that implementing only parts of Scrum is possible but the result is not Scrum.

For a solo builder or a pair, that raises a question of honesty. You can use ideas from Scrum with a team of one. You cannot be a Scrum Team of one in the Guide's sense, because the accountabilities are different people for a reason: the Product Owner decides what to build, the Developers decide how, and the Scrum Master helps the team improve. One person holding all three can do the work and cannot check herself in the way the roles are designed to. That need not stop you from borrowing, so long as you call it what it is.

The SBOK® Guide's view is broader: it says its concepts apply from teams as small as six members up to very large efforts, and mentions that the Scrum Master role can be held by a team member who learns to facilitate. A team of one or two is smaller than anything either source describes.

What startups share with Scrum's premise

The Lean Startup approach, which is influential among founders, holds that a company should invest its time building products that meet the needs of early customers, to reduce market risk, and should favour customer feedback over intuition and flexibility over planning. It proposes releasing a minimum viable product to learn quickly. These are Scrum's empirical themes in a business setting: learn from what has happened, in small steps. See the minimum viable product.

The match is real. Startups face complex, uncertain problems where the right product is unknown. They need short cycles, honest feedback and a clear current goal. Scrum's tools provide them.

What to keep

A Product Goal. One sentence about what the product should achieve. For a startup it is often the outcome sought by the MVP. Without it, every idea is equally urgent.

A single ordered backlog. One list, ordered by value and risk. Not a folder of ideas and a mind full of obligations.

Short cycles with a goal. One-week or two-week Sprints, each with a goal you can state in a sentence. The fixed time forces choices.

A Definition of Done. Even alone. "Deployed, tested, with a note on how I will know it worked" is enough.

A review with someone else. The feedback loop is the point. Show the work, weekly, to a customer, advisor or peer. A solo builder who shows nothing to anyone is not doing the inspection part.

A retrospective, even short. Ten minutes on what slowed you and one change.

A visible board. Seeing the work stops invisible overload.

What to drop or shrink

• A formal Daily Scrum. A solo builder plans each morning in five minutes. Two people can talk for ten.
• Sprint Planning as a ritual. A short session at the start of the week is enough.
• Estimation in points. Use rough sizes or none. The Developers must size, and with one person the overhead is not worth it.
• Burndown charts. A board and the Sprint Goal tell you the same.
• The separate roles. Write down which hat you are wearing. You need not pretend there are three people.

Getting the missing roles from outside

What is lost with one person is the outside view. Find substitutes.

• For the Product Owner's challenge: a customer, an adviser or a co-founder who asks "why this and not that?" at the weekly review.
• For the Scrum Master's coaching: a peer in a similar position, with whom you swap retrospectives monthly.
• For the Developers' accountability: a reviewer for the hardest code, or a pairing partner.

For two people, divide the hats: one holds the product decisions, the other the build decisions, and swap the Scrum Master duties, meeting the Guide's separation as far as possible. See can a Scrum Master also be a Developer.

A worked example

This is an illustrative solo founder building a scheduling tool for music teachers.

Product Goal: ten music teachers use the tool weekly within three months.

Rhythm: one-week Sprints, Monday to Friday. On Monday morning, twenty minutes to pick a Sprint Goal and the items. A board with four columns on a screen. On Friday afternoon, a thirty-minute call with two teachers who are early users, followed by ten minutes of notes on what she learned.

Sprint one goal: a teacher can set her weekly availability and share a link. Done means deployed and tested with one real teacher.

Review feedback: the teachers say that sharing a link is not enough, because parents want to see only the free slots for their child's level. She notes it and orders it above the invoicing feature she had planned.

Retrospective: "I spent a day on an animation nobody asked for. Next week I will check each item against the goal before starting."

Ten weeks later: fourteen teachers use it. Three features she once thought essential were dropped. She says the weekly review with real users did more than the planning.

She was not a Scrum Team. She used its ideas: a goal, short cycles, a definition of done, a review with outsiders and a habit of looking back.

Using AI tools

A solo builder with AI tools can produce a lot of code quickly, which makes the discipline matter more. The Product Goal and the Sprint Goal stop a flood of generated features from becoming a product no one wants. A Definition of Done that includes reading and testing what was generated keeps quality. And the weekly review with real users checks that fast building has not run ahead of learning.

Traps

• Calling it Scrum while skipping the feedback. The review with someone outside is the part most often skipped.
• Ceremony that eats the week. If planning, reviews and notes exceed ten percent of the time, cut them.
• Endless Sprints on the same ideas. If the goal never changes, check whether you are learning.
• Ignoring the business side. Scrum organises building, and a startup also needs sales, support and money.
• Treating the backlog as a promise. It is a list of options.
• Working alone in secret. Show the product early.

How to practise it

Write a Product Goal and a one-week Sprint Goal for what you are building, and book a review with one person outside the project for Friday. In the simulator you hold one role at a time with AI teammates covering the others, which is a way of seeing what each accountability contributes.