My house is more than 100 years old. The original structure was only two rooms, built in the late 1800s. Today there are eight rooms in total—the other six added on at different times over the last century as things like indoor kitchens and bathrooms became commonplace.
While I’m grateful that my home is larger than two rooms and has amenities like indoor plumbing and electricity, it’s obvious sometimes that the previous owners prioritized low-cost over long-term when expanding the house. For example, one of my exterior walls isn’t brick or siding—it’s just roofing materials screwed into wood.
My home renovation to-do list is so long that I gave up on keeping one. I work on the project a day here and a weekend there—whenever I find time. Luckily, the project isn’t time-bound. I have no deadline and may never finish everything.
Still, I want to be as productive as possible when I do find the time to focus on my fixer-upper, so I plan my projects using the Scrum framework.
What Is Scrum?
Scrum is a framework used by development teams who practice Agile, so it’s almost impossible to define Scrum without first defining Agile.
Agile is an approach to software development formed by a group of IT software development leaders in 2001. They were seeking a way to improve the software development process—make it more flexible, adaptable, and efficient. They met at a ski resort in Utah to brainstorm ideas. The outcome of that meeting: the Agile Manifesto.
Along with the Agile Manifesto, the authors documented twelve principles of Agile that advocate for things like collaboration, trust, self-organizing teams, sustainable work schedules, and continuous delivery.
While Agile is often referred to as a project management methodology, it’s probably better described as a set of philosophies. Agile doesn’t tell you how to work; it encourages teams to adjust how they approach and think about work.
Scrum, on the other hand, provides the "how" for Agile. It’s a process that provides instructions for applying the philosophies of Agile to project work.
Because Agile and Scrum are usually practiced together, the two terms are often used interchangeably, but they’re not the same thing.
Think of it in terms of sports. Players understand that while they all have unique talents, the best way to win a game is through teamwork. But they also use a playbook to execute specific scenarios as a team. The goal of collaborative work is Agile. The playbook is Scrum—an instructional guide for how to work as a team.
The Scrum Framework
If you want to understand all of the terminology and techniques of Scrum, take time to read the Scrum Guide. But since we’re discussing how to apply the Scrum framework to personal projects, I’m not going to cover all aspects of it—only those that apply to this specific approach.
Sprints
One of the core components of Scrum is the sprint. A sprint is a specific timeframe in which you plan to complete a set amount of work. Many software development teams work in two-week sprints, and the Scrum Guide advocates for time periods between one week and one month. But for a personal project, a sprint could be a weekend or even just a single day.
Backlog
A backlog is essentially a prioritized to-do list. Each task required for project completion goes into the backlog and gets ranked in priority order from most to least important.
Need help prioritizing? Check out this guide to using Agile prioritization for your personal projects.
Sprint Planning
The very first thing a team does at the beginning of a new sprint is plan their work for the sprint during a ceremony called Sprint Planning.
In Sprint Planning, the team reviews the highest priority backlog items, estimates how much time each item will take to complete, and plans the amount of work to take on given 1) the amount of time in the sprint and 2) the amount of time tasks will take.
If you have one day in a sprint and plan to work for eight hours, during Sprint Planning you would find eight hours’ worth of tasks in your backlog and plan to complete only those items.
Sprint Retrospective
At the end of the sprint, the team reviews and evaluates the work completed in a ceremony called the Sprint Retrospective.
In a Sprint Retrospective, each team member answers the following questions:
What went well?
What went wrong?
How can we improve in the future?
The goal of the retrospective is to create a list of lessons-learned that the team uses to improve how they work in future sprints.
Applying the Scrum Framework to Personal Projects
Let’s say I want to replace the exterior wall of my home that’s made with roofing materials. I need to tear down the existing wall, add insulation, and hang vinyl siding. I want to finish it over the summer because there will probably be times where I don’t have a complete wall, and I don’t want to sleep in a house that’s missing one wall when it’s below-freezing outside.
The first thing I need to do is create a backlog for the project: a list of everything I need to do. Theoretically, my backlog looks like this:
Purchase all materials needed for the project
Tear the roofing material down from the existing wall
Install any additional beams or framework needed for the new wall
Cut and install insulation
Install plywood needed to hang the siding
Install the siding
Paint the new siding to match the rest of the house
Once I have a backlog, I need to choose a timeframe for my sprints. The only time I can devote to the project is over the weekend, and while I might like the idea of completing some tasks Friday evening after work, I’m probably not going to have the energy for it. Each sprint, then, is one-weekend long, and I think I can do about 16 hours of work in each sprint.
Sprint 1
The first thing I do on the Saturday morning of my first sprint is Sprint Planning. I look at the highest priority tasks in my backlog and estimate how much time they will take. "Purchase all materials needed for the project" should take about 8 hours—one full day. I have to determine what I need, buy everything, and unload all of the materials.
My next tasks are "tear the roofing material down from the existing wall" and "install any additional beams or framework needed for the new wall." I think those will both take four hours each.
With eight hours planned for task one, four for task two, and four for task three, I’m at capacity—16 hours—for the sprint. Sprint Planning is complete. I don’t need to estimate the other tasks because I’ll plan those for later sprints.
Time to get to work. I start with research to find out exactly what materials I need to buy, make a list, and head to Home Depot. Unfortunately, Home Depot doesn’t have the siding I need in stock, so I have to make a trip to Lowes. Lowes doesn’t have it in stock either. I have to order it and come back to pick it up the next weekend.
In between researching and shopping, eight hours passed, and now I’m exhausted. I decide to unload everything the next day.
The next day I get up and unload all of the materials, then I’m ready to get started removing the old roofing wall. Unfortunately, it’s held up with screws that have rusted over the years, and trying to remove them strips the screws every time. I do some research and find out that I need a special tool called a screw extractor to get them out.
My local hardware store isn’t open, so it’s back across town to Home Depot. By the time I’m back home, the day is nearly over.
Since my sprint is over, it’s time to conduct a Retrospective. I answer the following questions:
What went well?
I have most of the materials I need for the project.
What went wrong?
Local stores didn’t have the siding I need in stock.
The screws I need to remove are rusted.
I had to make an unplanned trip to Home Depot.
Instead of completing three tasks, I completed 75 percent of a single task.
How can I improve in the future?
Call ahead or check store inventories online to make sure stores have everything I need.
Increase my estimates for how long tasks take to accommodate unexpected complications.
Sprint 2
I start with Sprint Planning, but I have to update my backlog to account for the things that changed after the last sprint. I cross my first task off because it’s mostly complete, but I need to add a new task for picking up my siding. Now my backlog looks like this:
Pick up siding from Lowes
Remove stripped screws and tear the roofing material down from the existing wall
Install any additional beams or framework needed for the new wall
Cut and install insulation
Install plywood needed to hang the siding
Install the siding
Paint the new siding to match the rest of the house
During Sprint Planning, I plan to complete the first three tasks. Because I’m reflecting on my lessons-learned from my last Sprint Retrospective, I’m going to call Lowes first to make sure my siding arrived. And while I think removing the roofing material and installing additional framework should only take four hours each, I’m going to estimate six hours each in case there are more complications.
Things are going well until the middle of the second day of my sprint when it becomes apparent that it’s going to rain. I need to go buy a tarp to hang over what I’ve removed, and I have to move the wood I was planning to install into the shed so that it doesn’t get wet. Because of those unforeseen complications, I only finish the first two tasks on my list.
In my Retrospective, I note the following ideas for improvement:
Check the weather before each Sprint Planning.
Wait to buy materials until I need them.
I continue with these processes every weekend until the project is complete. Because I’m taking the time to plan my work each sprint, I’m gradually improving my estimates and coming up with more realistic plans. And because I’m documenting the lessons I learn, I make fewer mistakes over time.
Accomplish More with the Scrum Framework
When working on a project, it’s easy to fall into the trap of powering through until you’re finished. But it’s not a sustainable way to work. Powering through work is fine for short, one-off projects. But if you’re working on something long-term—something like my never-ending quest toward total home renovation—Scrum helps for three main reasons:
It helps you work at a sustainable pace.
It provides a framework for planning work over time, giving you a better sense of when you’ll finish specific tasks and projects.
It provides time for reflection, which enables continuous improvement.
At first, it may seem like Sprint Planning and Sprint Retrospective ceremonies simply eat into the time you could spend completing tasks. But you’ll find that the time you spend planning actually improves your productivity by helping you find better ways to work and identify unnecessary tasks you’re focusing on that eat away at your productive time.
Related: Learn how to organize your life with the Agile Method and how to apply story points in Agile. And if you like this approach and are interested in tools to help you manage these backlog and sprints, consider adopting one of these free project management tools.
