You’re doing a one-person project and you feel like you need to manage your tasks more effectively? Maybe you should try Personal Scrum. This is the agile approach to software development but trimmed down extensively to support just about any personal projects of building just about anything – not just software. As Scrum brings immense improvement to a software development team’s productivity and satisfaction, personal scrum should also have a similar effect to a one-person project.
What is scrum?
Scrum methodology have gotten popular recently in software development circles. It has roots in Toyota’s just-in-time paradigm that says to only produce parts whenever there is a demand for it and only make just the right number of parts.
Scrum extends Toyota’s manufacturing paradigm this to an abstract backlog model. A product backlog is a mini-specification that describes a small part of the product. These gets translated into sprint backlog items which are tasks for the team to do and these tasks are broken in such a way that it should not take longer than a sprint to execute. Sprints are blocks of time, typically around 2-4 weeks long where the team executes tasks and then at the end of it comes up with a tangible product increment.
As you can see the work are broken into cycles and there is a result that is produced at the end of each cycle. Having a result at every cycle improves the team’s morale. Moreover the delivery scope of each cycle is fixed – i.e. there is no new requirements added mid-cycle. Any subsequent changes are postponed and handled as part of the next cycle’s delivery. This is how scrum takes care of scope creep – by visibly increasing the cycle count to take care of the additional requirements.
Scrum teams are usually self-contained software development team of 3–9 people consisting of a product owner which maintains the product’s vision and defines the acceptance criteria for each deliverable, a few software engineers, user interface engineers, and graphic specialists, and one half scrum master. The role of scrum master is primarily to moderate meetings and keep an eye of the team’s task list. Hence because the team is small, usually this role is taken part-time by another person in the team.
Although scrum is more popular in software development efforts, it is pretty much applicable to most other product development projects that are iterative in nature. Some of those are:
- Writing educational books (e.g. Lonely Planet’s Travel Guides)
- Producing television and radio programs (e.g. South Park and NPR’s TED Radio Hour)
- Designing a new car (e.g. Wikispeed’s SGT01)
If your project has these characteristics, it would probably could benefit from scrum:
- Have tangible mini-deliverables.
- Most tasks are pro-active (and not much fire-fighting going on).
- Team members has a shared objective of delivering a tangible product.
If you’re doing a one-person project that has a tangible result and you’re in control of that project’s schedule, scrum would be beneficial to manage your project’s tasks and deliverable. Applying scrum techniques would make you more focused and productive working on the project. No more “What should I do next?” questions that wastes hours every day since scrum’s planning processes makes sure that your queue is full for a given sprint.
You’d probably be better served by using a good to-do application that has a start date for each to-do item as well as the due date. This is so that you can input as many tasks as you need for your backlog items, however keep focus only on the tasks that are scheduled for the current sprint.
Better yet if the app can support custom views so that you can focus on just the current sprint’s tasks. That is, tasks that are supposed to be “in progress” as according to its start date. These custom views works wonders if you only have 1-2 hours a day to work on these projects.
First you need to decide how long your sprints will be. This will determine how often you deliver “product increments” and review your projects. If you have multiple concurrent projects, you should use the same cycle for all of them, so that you can review all of them on the same day. Take care not to take on too many concurrent projects or otherwise switching your head between the two may be too taxing. The rule of thumb is two concurrent projects is enough, otherwise you might consider to put some of them on-hold.
Two-week sprints would be best if you’re doing this project as a side-job. Otherwise if you’re a full-time self-employed or solo-entrepreneur, you could do well with a one-ish week sprint. Remember to spare at least half a day for sprint planning and review.
Then you need to break down tasks in the project into something that can be done within a sprint and produce a tangible outcome. Tasks shouldn’t straddle between sprints – if you keep finding that you tend to need more time to complete tasks, then you should really break these tasks into smaller chunks of work. Key in these tasks under your project and place them in a pending state. These pending tasks are the product’s backlog.
At every end of the sprint, you need to review the ending sprint as well as plan for the next sprint. Take some tasks off the backlog and schedule them for next sprint. It’s probably good to only have one major task (i.e. would take most of the time) and one or two other minor tasks for each sprint.
When planning for the next sprint, align the start date of each planned task to the sprint beginning and the due date to the sprint end. Later on this helps you to focus on just the tasks for the current sprint.
While in the sprint, try not to add any tasks to the current sprint. If it ends up that you have spare capacity, why don’t you spend it by planning for tasks to be done in the next sprint. In any case, there will be some fire-fighting (i.e. both important and urgent) tasks that falls through the cracks. Be sure to provision some spare capacity for these emergencies.
Implementing Personal Scrum in OmniFocus
OmniFocus is probably one of the few to-do applications for the Mac that you can use to do scrum. It’s uniquely defining features are defer dates and custom perspectives which seems rare among personal to-do applications.
To start, you’ll need to create a
@Context called Backlog and apply the on hold status to it. Whenever you create tasks for a scrum project, always assign the context to Backlog initially to indicate that this is something queued for future sprints.
Then you’ll need to create these two custom perspectives:
- This Sprint – use this perspective to focus on tasks available this sprint as well as any other fire-fighting issues that may occur.
- All Sprints – use this perspective to gain an overview of the upcoming sprints.
You’ll probably need the more expensive OmniFocus Pro edition (instead of the standard one) to have custom perspectives. But since you’ve gotten up to this point, you probably aren’t satisfied with simple to-do apps and would need a more fully featured application like OmniFocus Pro.
This Sprint perspective
Use the following settings to create the This Sprint perspective – allow everything else not specified here as default.
- Project hierarchy: Don’t use project hierarchy.
- Group actions by: Context
- Sort actions by: Due
- Filter by availability: Available
- Filter contexts: Active
- Sidebar Selection – add all contexts where you plan to work on your projects. However do not add the Backlog context – these aren’t to be done in the current sprint and we’ll want them out of focus.
All Sprints perspective
Use the following settings to create the All Sprints perspective – allow everything else not specified here as default.
- Project hierarchy: Don’t use project hierarchy.
- Group actions by: Defer Date
- Sort actions by: Due
- Filter contexts: Active
- Sidebar Selection – add all contexts where you plan to work on your projects.
You’ll need to create scrum projects as a parallel-type project in OmniFocus. You’ll also need to set the Next Review date to the start date of the project and the Review Every period to the sprint duration. Therefore each project review is a sprint planning & sprint review combo (but of course there is no sprint review on the first sprint).
During sprint planning, you’ll need to take a look at the tasks in the Backlog context and then move it to the appropriate context where you are planning to do the task. For example, if it’s a writing task that needs to be done on the computer, you could move it to the Mac context. Or maybe it needs to be done in a certain location, hence you can use OmniFocus for iOS’ location-based context.
Then set the task’s Defer until date to the following sprint’s start date (which is likely the day after sprint review & planning day) and the Due date to the sprint’s end date. You could also schedule tasks for the sprint after next in the same way by making use of the Defer until date. This would be an effective way to perform tasks that are dependent on each other or to break large tasks into manageable piece – schedule each piece in consecutive sprints.
When you are starting a task, Flag it. Then you can use the Flagged perspective to see all the on-going tasks that you have at a given time. Try to focus only on these flagged tasks and not to start a new one until these are complete. If you are blocked by someone else on a particular task, simply unflag it and take the next one.
Things to desire from OmniFocus
However there are some things that Omni Group can do to improve OmniFocus to make it more effective in handling scrum:
- A proper “in progress” state – a state between “available” and “done”, instead of making use of the flagged toggle to indicate tasks that are in scrum’s doing stage.
- The ability to create custom perspectives to filter by defer date. For example, to show only tasks starting next week. This would allow you to create a “next sprint” view by only showing tasks that starts no earlier than the current sprint end.
- An easier way to link tasks to show interdependencies between tasks. That is, to say that task X depends on tasks Y and Z but those last two are independent of each other.
- Shared tasks & task assignments. Now they have a cloud sync service, it’s probably not too difficult to share tasks between users and to delegate some tasks to them.
So that’s all folks. Please let us know how you apply scrum for your own projects.