In my previous post I spoke of my desire to be a writer, and my trouble with fitting writing into my schedule. I presented Agile methodology as a possible solution to this problem. I will attempt to explain myself here more fully.
First, though, I want to stress that I understand that no tool is going to get a novel written. In the end, if I am successful it will be because I sat down and wrote it. What this tool might help me with is to break up my writing tasks into smaller, more manageable pieces; when I have time, whether it be an hour or many hours, I will be able to find work that needs to get done that can be completed in that time frame. The trick will be to break each major task out into discrete pieces, and document each piece enough so that I can complete the work when necessary. As I complete more and more tasks I will be able to build paragraphs and chapters from those pieces, and eventually piece the entire book together. By breaking down tasks this way I will be able to identify things I can do in smaller increments of time – an hour here and there. Tasks that can be started and finished discretely with lesser need to be in full-on “writing mode”. At least, that is the plan.
It should also be noted that I’m only utilizing a small subset of Agile methodology. It is designed for larger-scale projects among groups of teams, and most of its particulars have little relevance to my problem.
To start: Agile methodology defines its individual tasks as “epics” and ‘stories”. An epic is a large picture issue, such as a new product feature, while a story represents a sub-task contained by the epic. A story can be a “feature”, meaning a new piece of functionality; a “chore”, meaning rework or refactoring of existing functionality; or “bug”, a problem with existing functionality that needs to be fixed.
The structure of my novel is of a present-time dialog intercut by scenes from the two main character’s lives. Each character’s scenes build that individual’s overall storyline. The scenes are not necessarily told in linear fashion, but in a logical progression. Each scene will be complete in and of itself but will either present or build on vital information for/from other scenes. There is also a character who acts as a semi-narrator, moving the plot forward in the segues in-between scenes.
I will map these ideas into fiction writing by defining them as follows:
- Epic: I will define at least four epics, two being a single character’s storyline and a third to represent the segue scenes connecting those scenes. I will also write an epic to represent the research that needs to be done to make my characters, plot and scenes believable.
- Feature: this refers to an individual, unwritten scene within an epic.
- Chore: this will refer to tasks such as researching a topic or going over a chapter or story that has been edited.
- Bug: this refers to the editing of existing content when I feel it is not yet up to par. I will also use them to refer to other rework issues, such as continuity issues or where a scene’s worthiness needs to be re-evaluated.
Also a part of Agile is the estimation of the time required to complete each story. This is usually done by taking some number system – say 1, 2, 3, 5, and 8, and rating each story one of those numbers. The actual time each represents depends on the length of a sprint (I’m setting mine to 1 week) and the discretion of the project manager. For this project, I’m going to enable 8 possible settings – the numbers 1 through 8 – where each represents an hour of my time.
Ideas for features, bugs and chores will be placed in a queue called the “icebox” initially. When I decide that they are actual tasks that I want to complete, they will be moved into the “backlog”. Projects that are to be worked on in the immediate time frame will be placed in the “current issue” queue.
Finally, I will define each sprint (iterative time frame for planning) as a period of two weeks. I will decide at the beginning of each sprint how many points I can complete in the next two weeks based on my knowledge of my schedule during that time. Based on that number, I will move items from the backlog into the current issue queue for me to focus on. Of course, if I find that I can do more than planned I can always pull stories from the backlog.
At this point, all of the information above is fairly theoretical. Next post, I choose a software tool to manage these stories, and discuss how I will use that tool.