Produce with Flow | Blog Home | Fractal Planner

Agile SCRUM for One (part 5): How I Do SCRUM for One

If you’ve read the first 4 parts of this series, you know that if you ever take on projects in your work or life that take months to complete, SCRUM for One can help you stay motivated, avoid a lot of second-guessing, avoid that gnawing impatience that grows over time, and create higher quality products and services that are more likely to be in-sync with the needs of your audience.

In this post I’m going to explain how I do SCRUM for One.

But first,

A Reassuring Note

In Clear Mind, Effective Action, I described a way to vastly simplify our work projects, and our entire lives.

Simplicity is a key factor for working with a sense of flow (which is our goal).

We are NOT doing SCRUM for one to add complexity to our lives. Our goal with SCRUM for One is to increase the feedback we get as we work on big projects, so we can work with more motivation, focus, and confidence.

And, because we wish to avoid unnecessary complexity, we will not be using the full machinery of traditional SCRUM.

In traditional SCRUM team members must coordinate with each other. In SCRUM for One we don’t have to do that.

In traditional Scrum, the team members estimate how long each task will take, and use the estimates to determine how much work they think can be accomplished in a given sprint, and to help determine who should do what. They also keep careful records of how long each task actually took. That allows them to see how actual performance matched up with estimates. If they don’t match up well, the team can figure out either how to give better estimates or how to improve performance.

We won’t worry about any of that. Feel free to experiment with time estimates if you want. For some people — those who want to train themselves to be more efficient as they work on tasks — that might be helpful.

I find it harshes my zen :-) So I don’t do it.

My goal is to work with flow so I can get more done with low levels of negative stress. I’d rather be 95% efficient with low levels of negative stress than be 100% efficient with moderate or high levels of negative stress.

So, now that we’ve seen some things we won’t be doing in SCRUM for One, let’s turn our attention to what we will be doing.

Jim Stone’s Current SCRUM for One Procedure

I’ve been doing SCRUM for One for a few months now. And I’ve settled into doing mostly week-long sprints.

Keeping things as simple as possible, my SCRUM for One process simply involves adding one additional plan into your planner, and having one planning session at the end of the week (for instance, the last hour of your workday on Friday).

I state it simply like this first, so you can see that it really doesn’t add much complexity to your life. In fact, it probably replaces stuff you’re already doing anyway.

So, looked at one way, it’s extremely simple. However, when you’re just starting, there are some details that matter. Because these details matter, I’m now going to describe my SCRUM for One practice as a multi-step process and discuss each step a bit along the way.

Step One: Start a New Sprint Plan in Your Planner

When I start a sprint, I start a new top-level task in my master plan, and I label it something like this:

“SPRINT to Friday, [date of the next Friday]: [brief description of the most important feedback-oriented milestone I want to reach]”

So, this week it looks something like this:

“SPRINT to Friday, August 26: Publish SCRUM for One Part 5 Post, Etc.”

Here’s how it looks in the Fractal Planner (the screen capture image came out a little fuzzy when I reduced it with GIMP.):

The first thing to note here is that there is a date involved. I would suggest trying week-long sprints at first. Sometimes a week will extend into two, because you bit off more than you thought you were biting off, or you ran into unexpected complications. So, if you aim at one week, you’ll mostly have one-week sprints, but occasionally you’ll have two-week sprints.

The second thing to notice is that this is a “top-level” project — a main project immediately under “master plan”.

Ideally, your sprint project will be the whole world to you for the week. So there’s no need to place the sprint under any other project heading. Keep it front and center in your attention by placing it at the top level.

It’s also “top level” in the sense that I’ve placed it at the very top of all my first-level projects. That’s a good idea, too, for the same reason.

You won’t deal with the rest of your plan much during the week You will still use it to keep a clear mind, dumping your thoughts about other projects as they occur to you, and maybe breaking them down a bit. But you won’t be working from your master plan during the week. In SCRUM talk, the rest of your master plan serves as your “sprint backlog”.

A final thing to note here is the rest of the description of your sprint project. There are many tasks you might want to accomplish for the week. And not all of them will be related. But you will usually feature just one in the title.

So, which item should define your sprint?

Here it’s good to remember the guiding principle for SCRUM for One:

The SCRUM for One Guiding Principle: Each sprint should end with an opportunity to get feedback from stakeholders.

For most of us our stakeholders will typically be our audience or partners or market or clients or customers or subscribers. But they could also be friends or family or consultants or others who can give helpful feedback.

And ‘feedback’ can mean lots of things as well. Perhaps ideally it means lots of sales or subscriptions for some product or service you offer. It can also involve getting survey responses from your audience, or comments and questions from them on a blog post. And it can also involve getting people’s informal opinions of your work or ideas at a given stage of development.

So, here are some examples of feedback milestones you might work toward:

  • Publish the SCRUM for One (part 5) post.
  • Finish the new sales letter for the blue widgets, and start testing it against the old sales letter.
  • Get a semi-polished draft of chapter 3 of my novel to my editor.
  • Create a “Clear Vision Wizard” for the fractal planner, and explain on the blog how it works.
  • Get the hot tub installed and host a party on Friday night.*

*Note: unfortunately these are just examples, and I’m not actually installing a hot tub this week :-(

Notice how each of these items is an opportunity to check in with your audience, or get feedback on a project from others. That’s important for all the reasons we covered in the first three posts in this series.

SIDEBAR: you won’t always be able to end the week with an opportunity for feedback. For instance, I just spent the last two weeks moving websites to a new server environment. That’s partly why you haven’t heard from me. Pretty much no one knows that that’s what I’ve been doing — which is good news, because I would have definitely gotten feedback if I had done it wrong :-) So I haven’t had any feedback for a couple weeks.

And you know what? I’m not feeling as motivated, focused, and confident about where I stand with my stakeholders (you!) right now as I would have had I had been producing valuable content for the blog, or adding features to existing software, or things like that.

Sometimes we have to do maintenance or “prep” work and go for stretches without feedback. And it definitely doesn’t feel as good as ending the week with an opportunity for feedback from the people who are important to us. In some ways maintenance weeks like that are the exceptions that prove the rule.

OK, so step one is to start a sprint project with some idea about what your main feedback opportunity will be, and how long your sprint will be.

Now let’s look at step two:

Step Two: Move Stuff from Your Project Plans to Your Sprint Plan

As mentioned previously, your master plan serves as your sprint backlog in SCRUM for One.

So, typically, when you decide which feedback milestone to pursue for the week, you’ll choose something that’s already in your master plan. And, if you’re following my advice about keeping a clear mind, you’ll probably find that you’ve already planned this part of the project out to some degree.

At this point you will simply drag the part of the project you want do this week from its place in the project plan to its new place in the sprint.

And now that you know you’re actually committing yourself to doing that part of the project this week, you’ll be motivated to take a closer look at your existing plan for that item.

Usually it will need some work, because the existing plan for that sub project was constructed on the fly as you were getting thoughts off your mind as you were working on other projects.

So just massage the plan for a bit until it looks like a good plan to work from for the week.

Then consider whether there are other things that have to be done for the week, and move them to the sprint plan (if they were already in the master plan), or create them in the sprint plan (if they are new items).

Finally, consider very roughly whether you have a week’s worth of work in your sprint.

Suppose there’s not enough work for the week. In that case you might just fill the sprint in a bit. You can pull other parts of your master plan into your sprint — sub projects or tasks that you think will be good to get done in addition to the feedback milestone you’re driving toward.

Or, you can expand your main goal and make it a bit more ambitious. Maybe instead of simply finishing a draft of a sales letter and showing it to a friend to see what she thinks, you can actually try to hook it up to an online sales funnel and start testing it by the end of the week.

On the other hand, if you find you have too much work for the week, you have a couple choices: 1) you can scale back your ambitions, and get a different kind of feedback at the end of the week, or 2) you can change the date on your Sprint to a date that feels more reasonable. I sometimes extend a one week sprint into a two week sprint for this reason.

OK, so it’s Friday afternoon, and you’ve got your sprint project ready to go for next week. Time to go home and enjoy the weekend. Or get ready to work again on Saturday. Your choice :-)

Next, we’ll look at how we work from our sprint plan during the week:

Step Three: Work Your SCRUM for One Plan During the Week

Now you just work your plan.

Remember to work with your natural energy rhythms as Loehr and Schwartz teach (and as covered in Clear Mind, Effective Action).

Try to work on your feedback milestone project before working on anything else. If possible, devote the first two solid working hours of your day to working on your feedback milestone project.

Do this before checking email, Twitter, Facebook, or any other source of distraction.

Do this before working on any of the other filler items in your sprint.

Make progress on your big project first, and you’ll feel great the rest of the day.

Most of the time that’s all there is to it. And most of the time you’ll coast into Friday having at least accomplished your main goal, and often you’ll get everything else in your sprint done as well.

SIDEBAR: Sometimes, as you’re working, you’ll run into unexpected complications.

Perhaps you will have an urgent and important interruption that will take over your week. If that happens, you can change the date on your sprint. Just move it out a week, deal with the interruption, and continue on. If the interruption just takes a day, or part of a day, you can make smaller adjustments.

But sometimes, as you’re working on a project, you’ll notice there are potentially fatal problems with the very project you’re working on.

Maybe your goal was to get a chapter of your novel to your editor, but you realized as you were writing that there’s a big inconsistency in your plot that will require you to re-think the structure of the whole novel. Or maybe you’re working on software and you realize that one part of the project just can’t be done like you thought it could.

Well, that’s not good. And, as always, the way forward is to face the problem, accept that the project won’t go as planned, and start planning a workaround or other strategy as soon as possible.

But here’s the good news. The structure of SCRUM for One helps you discover problems like this earlier than you normally would (see part 3 of this series for more on that), and that means you will create something that eventually works much faster than you normally would as well.

Step Four: Wrap Up Your Sprint

Finally, on Friday (in my example), you should process last week’s sprint (and then start the process all over again for next week.)

There are three main outcomes to think about:

  1. You finished everything in your sprint
  2. You reached your main feedback milestone, but some supplementary tasks were not completed.
  3. You did not reach your main feedback milestone.

Let’s look at how to close out the sprint in each of these cases.

A. You finished everything in your sprint

  1. Mark your sprint as “completed” in your planner.
  2. Start planning the next sprint.

B. You reached your main feedback milestone, but some supplementary tasks were not completed

  1. Create the sprint project for the next week.
  2. Move the items that did not get completed to the new sprint (knowing that you might demote some of them to the backlog as you plan for the next week if you no longer deem it a priority to do those things in the next week.)
  3. Mark the existing sprint as completed
  4. Start planning the next sprint.

C. You did not reach your main feedback milestone

  1. Decide whether you want to extend your current sprint another week or change the description of what your current sprint was about so you can mark it as completed.
  2. If you choose to extend your milestone, then re-label the date on your current sprint and use the current sprint for your sprint planning session to follow immediately.
  3. If you choose to change the description, then
    • change the description of the current sprint
    • create the next sprint project
    • Move all unfinished items to the new sprint
    • close out the current sprint by marking it completed.
  4. Start planning the next sprint.

Concluding Thoughts

So, to sum up, creative individuals can benefit from SCRUM just like teams can — only it’s much simpler for individuals.

In SCRUM for One you are the product owner, the team, the scrum master and the project manager, and your customers and audience are your stakeholders.

Instead of three different kinds of meetings, you simply do one weekly planning session in your last Friday work session (1 hour).

Instead of a shared and coordinated sprint log and backlog, you just use your master plan as it currently stands, and add one sprint project to it each week.

And that’s pretty much it. It really just boils down to adding one project into your plan and scheduling one planning session each week.

If you commit to doing this with all your big projects, you will get feedback much more often than you’re probably getting now. And that means you will discover more quickly when you’re going in a wrong direction, you’ll avoid paralyzing bouts of doubt, you’ll get more encouragement along the way, and your offerings will have a better fit with the needs of your audience.

As always, respectful comments and questions are welcome below:


Here’s how my master plan looks now:

And tomorrow I’ll start chipping away at the rest of this week’s sprint!

Have a great rest of the week.


This entry was posted in agile sprints, frequent feedback, SCRUM for One and tagged . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.


  1. Fatal error: Uncaught Error: Call to undefined function ereg() in /mnt/stor12-wc2-dfw1/606209/ Stack trace: #0 /mnt/stor12-wc2-dfw1/606209/ thematic_commenter_link() #1 /mnt/stor12-wc2-dfw1/606209/ thematic_comments(Object(stdClass), Array, 1) #2 /mnt/stor12-wc2-dfw1/606209/ Walker_Comment->start_el('', Object(stdClass), 1, Array) #3 /mnt/stor12-wc2-dfw1/606209/ Walker->display_element(Object(stdClass), Array, '5', 0, Array, '') #4 /mnt/stor12-wc2-dfw1/606209/ Walker_Comment->display_element(Object(stdClass), Arra in /mnt/stor12-wc2-dfw1/606209/ on line 262