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

Are you an indie developer who’s looking to get more done? Bring the power of Scrum to your app company with Ten Kettles’ one-person Scrum. By Alex Andrews.

Leave a rating/review
Save for later
Share
You are currently viewing page 2 of 4 of this article. Click here to view the first page.

Scrum of One: A How-To

Now that you’ve covered the Scrum principles of shipping, prioritizing productivity, and reflection/iteration, it’s time to get into the specifics. How can you use this technique to manage your one-person operation?

What follows is a one-person Scrum variant I created for my own work at Ten Kettles. I’ve stripped away much of the traditional Scrum jargon, so there’s no prerequisite Scrum expertise necessary. Let’s dive in!

The Sprint

A sprint is a set period of time devoted to a very defined goal, such as adding a new feature to your app or squashing a set of complex bugs. Pretty much everything you do in the sprint should be deeply focused towards making that goal (or set of goals) a reality.

A sprint is usually between one and four weeks, depending on your style and the product itself. I use two week sprints and find it to be perfect: enough time to get a meaningful set of tasks done, without giving me too much time to get off track or get carried away with unimportant tasks. Here’s what my two week sprint looks like:

Sprint Schedule

As you can see, a sprint is made up of lots of focus on your core tasks, plus a handful of events: the Daily Scrum every morning; the weekly Story Time; and then the Sprint Release, Retrospective, and Sprint Plan at the end. You can read about each of these in detail below.

The Daily Scrum (5 minutes)

One of the fundamental elements of Scrum is constant self-reflection and iteration — especially when it comes to productivity. So, when you plan to complete a task one day but it doesn’t happen, you use that as an opportunity to figure out what went wrong and then improve your process. The Daily Scrum helps make that happen.

The stand-up meeting (or Daily Scrum) is the hallmark of the Scrum method. Traditionally, it’s when the team members each share yesterday’s progress, today’s plans, and anything that’s blocking their productivity. The meeting’s kept short to prevent the dreaded meeting bloat (“just one more thing…”) and having everyone stand-up helps keep it that way.

At its best, a good scrum gets everyone on the same page, brings any challenges to light — eliciting help from team members — all the while helping the team to grow.

So, how can this work for one person?

Here’s where you can use a little tech to your advantage. Your one-person stand-up meeting becomes a short video you record every morning. (And I mean short: aim for under 45 s.) Here’s how you do it:

  • Review: Start by watching yesterday’s video, paying particular attention to what you said you were going to accomplish.
  • Reflect: Didn’t reach yesterday’s goal? That’s OK, this is what Scrum’s for: think about why it didn’t happen and what you could have done better. Maybe you booked a meeting mid-afternoon which threw off your coding flow for the rest of the day. Or maybe you were preparing screenshots manually for the App Store, and it took much longer than expected (time to try fastlane?).
  • Rehearse: For no more than a minute or two, rehearse today’s video: a couple sentences on each question: what did you do yesterday, what are you going to do today, what’s been blocking you. Here’s an example:
    Yesterday I created screenshots for hearEQ V2.2.0 and updated all the App Store meta information. Today I’ll update my press list, write a press release, and then meet with a music teacher to discuss Waay. For blocking, it took way too long to make the screenshots, and so I didn’t get to the press list as I’d planned to. Next time, I should look into speeding things up with fastlane!”
  • Record. Record the video on your phone, and you’re done! These will be particularly helpful in the Retrospective, which we’ll discuss soon.
Yesterday I created screenshots for hearEQ V2.2.0 and updated all the App Store meta information. Today I’ll update my press list, write a press release, and then meet with a music teacher to discuss Waay. For blocking, it took way too long to make the screenshots, and so I didn’t get to the press list as I’d planned to. Next time, I should look into speeding things up with fastlane!”

Story Time (30–45 minutes)

In each sprint, you’ll spend most of the time with your developer hat on — fixing bugs, adding new features, and so on — rather than devoting too much time to thinking about big-picture stuff, such as making a new app or pivoting a current one. Story Time is when you put on your CEO hat and start thinking big-picture. For this part of the sprint, I like to get out of my normal work environment and go to a coffee shop, grab some food at a local breakfast spot, or even just work from a different area of my home.

Changing up your location — even to a different room — helps you think about the big picture.

During Story Time, I’ll review feedback from users, brainstorm app features I’d like to add, and consider how I might want to pivot the apps (or even the company). This is also the time that I’ll think about new apps or abandoning old ones. Then I’ll come up with some concrete ideas and add them to a special list called the Product Backlog.

The Product Backlog is an ordered list of big-picture tasks. This will be the first place you’ll look when deciding on your goal for the next sprint. But just as important as it is to add new tasks to your backlog, Story Time is about revising and rearranging what’s already there.

Maybe you’re seeing a lot of interest from Brazil in your website analytics. That could mean it’s time to consider a Portuguese translation instead of the Spanish translation you had planned. Or maybe you’ve just received some reviews about a feature that people suddenly seem to want. Time to consider moving that feature up the list.