I’ve been doing software for long enough that I have seen a silver bullets: methodologies that will magically slay the monster of out-of-control development times, while banishing bugs and washing whiter than white.

They don’t, of course. Software is an unpredictable thing to make because of its innate complexity: the approaches which are most durable are those which emphasise adaptability. All of these are built on iteration, and the best of breed are the agile methods*. These cover best practices for development, testing, requirements gathering, and signing up for tasks, but the bit which is most revolutionary and which can be applied to any project – including, of course, writing – is the task tracking mechanisms.

In a standard project plan (for example, a Gantt chart or any kind of dependency graph) you would go through your list of tasks and make an estimate of how long you think it will take. Then you’d break down the task into smaller pieces and fit the work into the initial estimate. If you’re smart (or lucky, depending on circumstances) you’ll adjust your overall estimate based on how long the sub-tasks take, but you would still make an overall estimate and then work towards that. The thing you make is based on the initially agreed features, and the release will slip if any of those features are not ready.

What agile methods do is to set a fixed interval for releases, and then divide up that interval into short work periods called sprints – two weeks is a pretty common sprint length. Classically, you would be ready to deliver at the end of each sprint although I’ve never worked that way. Rather, you pick tasks that will fit into the sprint. When you are making estimates, you always pick tasks that you can estimate at two or three days of effort. If a task is too big to manage in that time, then break it into smaller tasks that can.

Here’s the clever bit.

At the end of each day, you estimate how much effort is left on the tasks you have. This is called the burn down.

That doesn’t seem terrifically powerful, but it means you can adjust: if a task is more complicated than it appeared at first then you can expose that early and get help or push out tasks to the next sprint that will no longer fit. If a task took less time than initially expected (it does happen…) then you can pull in more tasks, or help someone else who is having trouble. The analogy often drawn is between firing a gun and driving a car: everything about firing a gun is in the aim, whereas when you’re driving a car you make adjustments and steer the car as you go.

This task tracking is what I like to use for other projects. I will generate a list of broad project activities, and then break each activity into more specific tasks. For a novel, this may be outlining, then a list of scenes or chapters to be written, then reviewed, then edited, and so on. In point of fact, during the drafting process the novel is its own progress metric since you see the word count climbing and the number of completed chapters rising, but for some tasks which are bit more gnarly then the burn down chart may be more immediately useful. A burn down will help tell you if you are writing a lot more or less than initially planned, anyway.

Another major benefit of the burn down is that you can learn how long it really takes you to do particular kinds of tasks. If you always estimate consistency edits on a chapter as taking two days, but it always actually takes you three then you have the information to learn that you should start estimating it at three days in the first place.

How do you track a burn down? Well, you can find tools on the web although they are mostly not free and tend to be tuned towards software development. And really, you don’t want to be learning Rally unless you have to. For my own projects I tend to either work in a spreadsheet or a text table.

Let’s consider a short story project, for example, since that might conceivably fit into a two week sprint. I’m going to name the sprint Pony, for reasons which will become obvious, and I’m going to assume a six day week, and that you can write for two hours a day. All estimates are in hours.

Pony sprint – a short story about poniesEstMTWTFSMTWTFS
brainstorm pony story ideas2
outline story2
write first draft4
edit for consistency4
edit for plot4
edit for character2
edit for word choice2
Time left242220181614121086420
Total (hrs)27
Total (%)112

The top line of the left column is the sprint name, and its theme (an entirely optional element, but useful to give overall direction). Most of the rest of that column consists of tasks you think you need to do for the story. Other stories might need more research tasks (what do ponies like? How much sleep do they need? Would an unfamiliar pony be eaten by the herd?) but here I mostly have writing tasks. Then at the bottom we have headings for the time totals.

The second column is where the numbers start: an estimate for how many hours each task is expected to take. The totals at the bottom of the column are the number of days left multiplied by the amount of time available at the end of each day – this is the time left in the sprint – and totals for the hours expected to be worked and the percentage of those hours compared to time left. The percentage (also called loading) is particularly interesting, because it gives you some sense of how likely you are to finish in the sprint. In this case, high is definitely bad… normal loading at the start of a sprint in a software project would be 80-90% to allow for the unexpected.

The remaining columns are the days in the sprint. I’ve labelled these with days of the week, but calendar dates are more usual.

As you progress through the sprint, at the end of the work period you note the hours remaining to be done on each task. So, if at the end of Monday the brainstorming is done and you’ve made a good start on the outlining, then you can complete one task and burn off some time from another. Then you add up all the remaining tasks and recalculate the totals at the bottom.

An obvious benefit of a spreadsheet is that all this adding up can be done for you.

So, let’s look at this burn down chart after a week.

Pony sprint – a short story about poniesEstMTWTFSMTWTFS
brainstorm pony story ideas20
outline story210
write first draft4420
edit for consistency444330
edit for plot444442
edit for character222221
edit for word choice222222
Time left242220181614121086420
Total (hrs)272219161610
Total (%)112100958910071

From this we can see that the brainstorming went well (zero hours left) and outlining was started early (one hour remaining). The outline was completed and first draft was started and half done on Tuesday, then complete a day early on Wednesday. The consistency edits went slower, either because there were more problems than expected which needed fixing, or because other things popped up that interfered with the work (on a software project, I would usually add tasks in to document these other things, but that’s not really appropriate here). Finally, at the end of the week, the plot editing started along with some character tweaks.

Looking at the loading along the bottom, you can see that it dropped below 100% on Tuesday and kept falling, but drifted back up as the first edit task stalled. However, that was recovered at the end of the first week and this story looks like it will be finished by the end of the two weeks.

Is this tool for everyone? Not at all, but I find it useful to keep me motivated. There’s a gamification** element here – the game is to keep the load as low as you can – which makes this quite a fun planning tool as well.

[*] there’s a whole cluster of these, but a full history is not very relevant here. The first widespread one was XP (eXtreme Programming) and the one I have encountered most frequently in my professional life is Scrum.

[**] yes, this is a hideous word, but it is a term of art which captures a useful concept of making otherwise intractably large tasks manageable by turning their completion into a game.

Leave a Reply