Posted On: 2021-02-08
As I work through outlining and planning the narrative arc that I'm currently working on, I find myself (inadvertently) applying Agile software development habits to my writing process. While many of these are simple differences of perspective*, there are a few that have provided unexpected benefits. Today, I'll explore one of those: how using Scrum's User Story pattern to break up my writing is giving me unexpected insights into my project's outline and structure.
In Scrum (a particular implementation of the Agile methodology), large-scale objectives are ordinarily broken into User Stories, which describe a particular piece of functionality from the point of view of a user who would benefit from its inclusion. By making them a story (rather than a mere description), Scrum aims to build empathy with the customer: to help the developer see their product through the customer's eyes*. Additionally, this also has the benefit of making clear the reason why any particular work item is being included: User Stories tell you why they matter, which is a massive boon when outstanding Stories (inevitably) have to be shuffled/cut.
When I tried creating User Stories for my outline, I immediately found that it enhanced my outline substantially - by making explicit the various implicit benefits and connections within the larger whole. Where the outline says what happens, a User Story augments that by providing an explanation for why it happens - not in the context of the fictional world, but in the context of what emotions/thoughts it imparts on the audience experiencing the work. For example, where the outline calls for Character X to learn fact Y, the corresponding User Story instead calls for the reader to become aware of fact Y because it will make the (later) reveal of fact Z especially shocking.
This benefit is particularly pronounced as I approach items on the outline that induce divergence. Optional paths, branches on the main story, or places where the story reacts to prior experiences are particularly high-cost (compared to a linear romp.) Through User Stories, I make explicit the benefit that justifies the cost associated with each divergence: how does the player feel the impact of their choice? What does the act of choosing add to the player's experience - either in that moment or in the greater story overall*.
I am still fairly early in the process of creating User Stories for my writing, so I'm not sure whether I'll be able to use User Stories in the same way Scrum does. Ordinarily, once enough User Stories are created, I would go on to estimate the Stories, and then plan and execute Sprints composed of such Stories. I am, however, a bit skeptical whether that approach will apply as well when I try to apply it to a written work.
Much of the flexibility and power of Agile development stems from the ability to revise as you go, reprioritizing and cutting in response to user feedback. While writing does rely heavily on feedback (largely from alpha readers), it is generally resistant to reorganization, as the efficacy of later parts of the story often depend on readers' understanding of earlier parts of the story. Thus, I am uncertain how much flexibility I will actually have with regard to planning and execution: it very well may require that I do all the writing* in order, simply due to how the narrative dependencies work out.
Hopefully this exploration of how I'm using my Agile habits to enhance my writing process is interesting. While it's unclear how far those habits will continue to help me, I am confident that, at the very least, the creation of User Stories is helping me to get a better handle on how my story works. As always, if you have any thoughts or feedback, please let me know.