I struggled for years with motivation to write and periodic burnouts, and I know I’m not alone. For every author I see putting out a book every year, there are many who struggle to meet their word-count goals or lament their inability to write every day.
We want to get more done, or worse, we feel like we “ought” to get more done. When we fail to live up to that (sometimes unrealistic) standard we set for ourselves, we lose hope and even feel a lack of self-worth. Writing requires emotional energy, and when that energy is drained by these perceived failures, we can burn-out: unable to write until we refill our tanks.
Agile Writing
I’ve found that the most effective way to avoid burnout is to be honest with yourself about what you can actually accomplish. That sounds simple, but it takes some real work to figure out just how much you can do, and it’s not a static formula — it can change over time.
My day job is in software development, and I often find that writing software is similar to writing fiction. It’s not always obvious going into a project how much effort it will take. The software industry has spent decades and untold millions of dollars trying to better understand how to estimate the time and effort necessary to complete projects.
In this post, I’m going to talk about the modern Agile software development methodology, and how we can apply some of its lessons to writing.
Prioritize, Break Down, Estimate
To get things done, you have to know what things you’re doing. That sounds obvious, but it’s easy to jump into an exciting project head-first, without realizing that you don’t entirely know what the whole project entails.
Any large pieces of work get broken down into the small tasks that compose them. Having “write novel” as a task isn’t useful. Split it into individual scenes or chapters (or developing a character, etc., etc.)
Before you can work on a task, it needs to have an estimate. This is your guess as to how long it will take. You can try to estimate in real-world hours, but many agile teams find that counterproductive. They’ll often use a small set of options, like T-shirt sizes (S, M, L, XL) or nonsense units like jelly beans (1, 3, 5, 7, 10 jelly beans).
Having a limited set of options avoids wasting too much time trying to zone in exactly on a perfect estimate, because it’s unlikely any estimate will be perfectly accurate anyway. If it’s not quite an M, it’s got to be marked as an L. If it feels like four jelly beans, it needs to be marked as a 5.
Units that aren’t actual time will be useful later on, when it comes to evaluating your estimates. You might decide that a S is a day of work initially, and later come to realize that it’s more like two days of work. That’s no big deal. But if you use real-time estimates, you’ll have tasks marked 1-day that are actually 2-days of agile-time. Your estimates will get confusing quickly.
I like to use Trello for tracking my writing tasks, but there are plenty of other applications that will do the job. You can also use good old-fashioned index cards or post-its.
Sprinting
The Agile process breaks down time into “sprints,” which typically range from a week to a month. At work, I use two-week sprints. For my own work, I use one-week sprints.
At the start of a sprint, you estimate how much work you can get done. Then take tasks from the backlog and put them on the sprint until the estimates fill up the time you allocated for the sprint. If you can’t fit exactly, it’s better to go under the estimate than over. Try to be honest with your task estimates, and how much you think you’ll be able to finish.
Next comes the real work! Pick tasks and finish them. If you get them all done and you still have time left, you may want to grab another task or two from the backlog. On the other hand, if you don’t get all the tasks done, that’s okay. Think of each sprint as more than an organizational tool. It’s an experiment. The goal of the experiment is to research how much work you can typically get done in a sprint. Don’t worry or freak out if a sprint goes badly. (In fact, it’s pretty normal for a first sprint to be a bit of a mess.) Instead, get ready to evaluate your progress and make adjustments.
Reviews
The sprint is finished. It may have gone well, terribly, or about as expected. The first few sprints are more likely to be rough, as you’re learning the process and have rougher estimates. You may discover that you thought (or hoped) that you’d be able to get a lot more work done than you actually did. That’s good. The experiment yielded some meaningful results.
In the Agile process, a review is held at the end of each sprint. This is an opportunity to evaluate how things went. Look over the work that was finished. Firstly, be proud of what you accomplished. Then, spend a little time thinking about the estimates for your tasks and for the sprint as a whole.
If you were able to get everything done with ease, consider adding more estimated time to your sprints. But be wary! Sprints will naturally vary. Like all solid science, results have to be repeatedly verified before they can be taken as fact. Before you make wild changes, look for trends across multiple sprints. This will be much more reliable than a single result.
If you weren’t able to get everything done, first look at individual issues. Did some take longer than estimated? Sometimes this happens when tasks aren’t broken down well enough, or aren’t clearly defined. You’ll find pretty quickly that smaller tasks are easier to estimate accurately than larger ones. It’s easier for bad assumptions or unexpected snags to throw a large task off-course than a little one. You might also find that a task ended up being harder than expected, in a way that was difficult to foresee. Don’t stress too much about it.
In software, there are two things that most teams work constantly to improve: breakdown of large tasks into small ones, and accurately estimating those small tasks. But there are other problems that can mess up a sprint. Sometimes the real world steals away your writing time — your in-laws decide to stay for a week, you have a family emergency to work out, or a broken furnace needs your attention immediately. Consider the circumstances around your sprint. It’s normal that you’d get less done in that kind of situation. You can take solace in a new sprint and a fresh start.
What’s the Point?
When Agile started getting popular in software, a lot of teams balked at it. Some still do. Why do all that obnoxious estimating and review? It’s more time in meetings when the “real” work could be getting done. You might feel the same way at first. Try sticking with it for a while.
Firstly, the planning and review that feels so onerous when you’re starting out becomes easier and even satisfying with practice. Breaking down tasks becomes second nature.
More importantly, this is a way to evaluate your expectations, your actual output, and why they might not be aligned. If burnout happens because we expect more from ourselves than we can deliver, then we need to come to grips with the gap between those two things.
Your sprints may show that you finish 75% as much task-time each week as you first expected. Your sprint reviews might make it clear that you’re consistently under-estimating how much time chapters take to write. They might tell you that you have an outside interruption almost every week that keeps taking time away from your writing. Understanding these problems is the first step in addressing them.
Ultimately, you may find (as I did) that you just can’t get as much done in a week as you wanted to. That can be okay too. I have a regular 9–5 job and children. I’m an inveterate planner who doesn’t write that quickly. I have to accept that I can’t write at Stephen King pace. And that’s okay.
Words Deferred 