← Writings

Project Management for Indie Hackers

03 Aug, 2022

Introducing SCRUM

SCRUM is a term borrowed from Rugby, where it means a formation of players. Similarly, in product development, SCRUM is a way to manage a team in order to build a product.

How does it work?

In order to ship a product using the SCRUM method, we divide our timeline into 1-2 week blocks called Sprints. The goal of each sprint is to ship a fully ready feature of the overall product into production. At the end of the last sprint, the cumulative effort of all the sprints yields a shippable product with all the planned features.

Walk me through it

At the very start of the project, the product owner will create a list of features that need to be built before shipping the product. This is called the Project Backlog. The backlog consists of features which are also called User Stories because they are often formatted as such:

 

As a user of this product, I need FEATURE X so that I can do USE CASE Y.

 

Example: "As a daily user of this meditation app, I need regular notifications to breathe mindfully so that I can achieve the goal of reducing my daily stress."

After the backlog is ready, the first ceremony of SCRUM is held - The Sprint Planning. During this phase, the project owner and the team gather together to decide on which tasks to prioritize for the next sprint. The outcome of this meeting is the Sprint Backlog. This document contains a list of features which have been committed to be completed in the next sprint.

Finally the sprint begins. During this 1-2 week time, the team members work on building the features, while the product owner assists in ironing out any wrinkles that arrise during the development process.

During each sprint, there is a daily ceremony called the Daily Standup or Daily SCRUM meeting during which the team and the product owners discuss what they have completed, what they have worked on, and any roadblocks they have encountered.

At the end of each sprint, there are two further ceremonies - The Sprint Review, and The Sprint Retrospective. During the Sprint Review meeting the team will showcase the outcome of their sprint. During the Sprint Retrospective meeting the team brainstorms about what they can do to be more efficient.

In the end

At the end of a sprint, the product owner decides whether the outcome of the sprint can be shipped to the final product. The product owner then consults the Project Backlog and repeats the process above for the next set of features that need to be built.

The SCRUM method may not be useful when shipping MVPs or micro-projects that have at most 1-2 features. The beauty of SCRUM is seen when a group of individuals need to work on a large project with multiple features. Due to the nature of such projects, it is difficult to answer how to build such a large project, or what to build first. This is where SCRUM helps by breaking down the product into smaller chunks and by prioritizing features based on what is most important from the user's perspective (see User Stories).

Why Indie Hackers should use SCRUM

SCRUM adds structure to your product development process. I don't know about most of you, but until  recently, I relied on caffeine, and motivation to ship a product. However, the impact of these wanes as the weeks go by. Additionally, indie-developers need to be aware of how often they are shipping. If you don't ship regularly (say 1-2 weeks) you risk never shipping at all.

With SCRUM, you can build products iteratively so that you're not building a bloated MVP. Each sprint focuses on shipping something at the end of it, therefore ensuring your shipping muscle doesn't attrophy. Using documents like the Project Backlog helps you stay aware of what needs to be built, and in what order. By going through a Sprint Planning session, you have a reliable way to know what needs to be built vs what is easy to build (writing that blog post is probably more important than changing the color of that button).

SCRUM is not just for big companies, but for anybody who wants to ship products reliably.

Footnotes

1. If the feature can be completed within the timeframe of a single sprint, it is added to the backlog, else it is recurssively broken down into smaller sub-features until the sub-features can be completed within the timeframe of a single sprint.