Trello – Words Deferred

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.

As a part of this Reference Desk series, where I look at useful tools for authors, I’ve now shared most of the software that I use for writing. I covered Scrivener, where I do most of my novel writing. I talked OneNote, where I keep my notes, from story brainstorms to blog posts. Finally, I discussed Dropbox, which I use to back up all my writing work.

However, there’s one more application that I use, for a different aspect of writing – organization and planning. That software is Trello.

I remember seeing Trello when it was first released, and thinking, “Is this really all it does?” Even the Trello website is a bit cagey when describing it, using all sorts of business buzzwords, like “collaborate,” “manage,” “productive,” and “organize.”

Personally, I use Trello to keep track of my weekly to-do list around the house. I use it to plan meals (at least when I’m feeling like a competent adult). I use it to track short stories I’m working on, and what stage of development they’re in. Sometimes I use it to track revision notes or prioritize my projects.

Boards, Lists, Cards

Trello doesn’t dictate a rigid form or structure. It just lets you make lists of things. Shuffle them around, color-code them, or check them off as you get them done.

An accurate (if not thrilling) description of Trello is “an app that makes very flexible lists.” Lists are one of the simplest and most effective ways to take complicated things, big things, and break them down into small and manageable things. That’s what I use Trello for, and that’s what it’s good at.

Trello lists are built from a few simple components. At the top level, there are “boards.” On each board, there are multiple ordered “lists.” On a list, you have “cards.”

Cards have a title and can have a description. They can have little color-coded labels, or comments, start dates and due dates, checklists, pictures, or other attachments. Cards are where the action is.

Simple and Flexible

You can think of Trello as a big cork board. Lists are just columns of index cards, pinned onto the board. You can move them between columns, or up and down a column. But cards are also like file folders, and they can have all sorts of interesting things inside them. From that basic structure, you can organize in whatever way seems natural to you.

The most obvious example is a to-do list. Make a board with three columns: To Do, Doing, and Done. Fill the first column with tasks. When you’re ready to do a task, move it to the middle column. When you’ve finished it, move it to the last column. When everything is done, close the board.

Of course, you can embellish the bare-bones process. You can shuffle tasks in To Do so they’re in the order you plan to do them in. You can color-code them by importance, or amount of effort, or both. You can add a picture to each one. You can add addresses or phone numbers or web links.

You could expand the basic To Do list into a writing board. Perhaps you want more columns: Ideas, Incomplete Drafts, Complete Drafts, Published, and Shelved. Then add a card for each of your stories. Some small story seed might end up as a card in the Ideas column with just a vague title and a few words. As it moves, it could accumulate more ideas, inspiring photos, character bios, and so on.

You could attach the story document directly to the card, or add a link to your cloud backup. You could maintain a list of the magazines you’ve submitted that flash fiction to. Heck, you could attach copies of rejection and acceptance letters.

Hopefully, you can see that these very simple tools can be put together in a lot of ways. Part of what I like about Trello is that I get to figure out how I like to do things over time, and I can adapt my process accordingly.

Collaboration and Synchronization

Trello is an online tool, so your updates are automatically saved and available across devices – computer or mobile – as long as you’ve got internet connectivity. They have the usual iOS and Android apps. I use Trello on my phone about 95% of the time, and it works well.

I use Trello almost exclusively for my own boards that nobody else needs to see, but I have shared boards with my wife in the past, and the changes and sync between the two of us were seamless. Trello is obviously trying to sell to the “enterprise” team crowd, so if you want to coordinate with a few writing or business partners, it shouldn’t break a sweat.

I’ve found the free plan to be more than adequate for individual use. The main limitation that you’re likely to run into is a maximum of 10 open boards. So long as you aren’t updating more than 10 boards on a regular basis, you can always close old ones and stay under the limit.

If you do need more boards, need to upload big files, or want to use some of the serious team collaboration options, the next tier up is about $120 per year.

One Small Caveat

It’s worth noting that Trello was recently acquired by Atlassian, a huge enterprise company that specializes in tools for software development. Thanks to my day job, I’m familiar with most of the Atlassian tools. They’re about as powerful, expensive, rigid and occasionally clunky as you’d expect from software that has big-business plans with prices listed as “Contact Sales.”

Trello has been slowly but steadily adding features over time, and that’s continuing under the new regime. So far, I haven’t seen any unsavory pushing of paid options or favoring big business over individual users. But there’s always that possibility when smaller start-ups are eaten by their older, larger competitors. Time will tell whether Trello influences Atlassian, or vice-versa.

Try It Out

If my description of Trello sounds interesting, I encourage you to try it out with a free account. The only advice I’d offer is to try to come up with more than one way to do things. Play around with it. One of the big advantages is freedom and flexibility that so many apps like this lack. You may find that the flow that ends up working best for you isn’t quite what you expected.

Tag: Trello

Writing Schedules and Avoiding Burnout