Scrum of One: How to Bring Scrum Into Your One-Person Operation

Sprint Release

A fundamental principle of Scrum is getting your work out into the world on a regular basis. This is what happens in the Sprint Release. It doesn’t need to be a full app release, but it is really important that you get something new out into other people’s hands — especially people who you feel a little nervous to impress! This can be a new version out to your Beta testers, a set of wireframes out to a new designer you’re really excited to work with, or even a minor update out to some discerning internal testers.

The scope of your release will likely change throughout your sprint, especially at first. For example, maybe you’ll end up releasing a Beta with only two of the three planned features. That’s OK. By trimming down the scope as you approach the release date, you prioritize the most important features without delaying that valuable tester feedback. If your testers don’t even comment on the missing feature, maybe it wasn’t all that important. If they do, then you have a clear idea of what to prioritize in your next sprint!

Last Day of the Sprint

You’ve spent nine days working towards your sprint goal, and now it’s time for the final day. The good news is that this is an easy one — you can keep your developer hat in the closet for today! :] This is a day to do a Retrospective, wipe the slate clean, plan your next sprint, and then do something fun.

At first, this seems like a very odd thing to spend a day on — especially if you’re drowning in deadlines. But I think of it like this: when I was young and walking home from school, I’d sometimes read a book as I walked. If I was really engrossed in the book, I’d find myself constantly zig-zagging across the sidewalk as I almost tripped into the road on the one side, or into someone’s garden on the other. (Agile, indeed.) And if I didn’t look up often enough, I might even end up going the wrong way.

Making sure you’re on the right path is what the last day of your sprint is all about. It’s a single day (or half-day, if the pressure’s really on) every two weeks where you pull your head up, look around, and make any necessary course corrections. Because even if you’re being super productive, that productivity isn’t worth much if it’s being wasted on the wrong task.

Now, let’s jump into the three main tasks for the day.

Retrospective (~2 hours)

Open up a new text document or turn to a fresh page in your notebook, and start writing down your thoughts about the past two weeks’ productivity. Here’s your opportunity to discover what’s stopping you from becoming even more productive and happy.

Some sample questions to get you started:

• What did you accomplish?
• Did you meet your sprint goal?
• What worked really well this sprint? What could have worked better?
• Are there any productivity blocks that kept cropping up? Review all your Daily Scrum videos for this information.
• Is there anything that needlessly stressed you out, or that you really enjoyed?

If you find that a walk is better for reflecting than sitting at a desk, hit the pavement and simply type up a quick summary afterwards. I also find that doing this outside of my usual work environment is helpful too.

Sometimes a walk in the woods is just what you need for a good Retrospective task.

Sometimes a walk in the woods is just what you need for a good Retrospective task.

Finally, based on your reflections, pick two simple things to improve on in your next sprint:

1. One thing to make you more productive.
2. One thing to make you happier.

Here are some examples of reflections from my recent sprints:

• Productivity: Especially during a Beta testing period, I found that constantly jumping in and out of email was really slowing me down. I started limiting email checks to three times over the workday, and it definitely helped my focus.
• Happiness: Because I work from home, it’s sometimes difficult to transition from “work mode” to “home mode” at the end of the day. So, I started taking a long walk at the end of each workday to “reset” before the evening. This one was a big success!

Sprint Plan (~2 hours)

Between the Retrospective, the two Story Times, and your Product Backlog, you should have a pretty good idea of what to work on for your next sprint. Just pull up that well-maintained backlog and pick the top few items! Your Sprint Planning stage is when you write down those sprint goals, the tasks that’ll take you there, and assign something called Task Points. More about that in a moment.

Here’s a simple example. Let’s say you have an app almost finished, and your next sprint will be for adding that final feature, doing some internal testing, and then putting out a Beta for user feedback. In your Sprint Plan document, lay out something like the following:

Note that for a two-week sprint, you’d likely have a lot more tasks here! But it’s enough to illustrate the point.

See those numbers beside each task? They’re called Task Points. They don’t represent hours or anything readily measurable — they’re completely abstract. All that matters is consistency.

For example, a one-point task should take about half as long as a two-point task (on average). Use whatever you like for your own scale. Personally, I like to use the numbers 1,2,3,5,8 which have a way of correcting for our human tendency to underestimate bigger tasks. For example, because there’s no 4, I have to round up to 5. :]

As you lay out your sprint’s tasks, think about how long each one will take relative to the others. Throw hope out the window here; take a cold and calculating look at each task and make a reasonable prediction for how long it will take you to complete.

If a task is complicated, but you’ve done that task a million times, then it will go a little faster and you can reduce the points. If a task is simple, but you’re unfamiliar with it, it will take longer and you should increase the points allocated to that task. No problem.

When you’re done, simply add up all the Task Points and compare the sum to what you achieved over your last few sprints. For example, if you usually get through 80–100 Task Points in a sprint, make sure this next sprint has around 80.

This is one of the most effective parts of Scrum, in my experience — and the most difficult. It’s often at this point where I find myself cutting tasks that I want to do in favor of tasks that are important to do. This gets me thinking more like a CEO than a developer, which can be helpful from time to time.

Now, once you’ve got your Sprint Plan down, clear off your Task Board from your last sprint, and prep it for Monday!

Wait, what’s a Task Board?