Doubt.  A writer’s worst enemy. Often the cause of ‘writer’s block’ or ‘starting a new book to abandon four chapters later,’ doubt is stealth in how it can derail an otherwise smooth writing life. Eliminate doubt and all our writerly dreams will come true!

Or will it?

I decided to ‘measure’ how much doubt was floating in the Twitterverse this week, to calibrate my perception vs. reality. Our connected online world makes it easy to peek into the writing process and day-to-day of authors from every stage. Fresh faced first bookers, the several books and querying agents, agented but not contracts, first contracted book and those with multiple books and even authors hitting The Lists.

Guess what? Doubt’s on every desk and every mind at some point in the process. It’s part of the process.

Instead of swiping it away, maybe we should invite Doubt in, give it a special spot on the desk and accept it as part of our process. Got doubt? Excellent! You’re ready! Now go write

I’ve spent insane amounts of time thinking Process in the day job, as the software development industry continues pushing for more features and better quality with fewer resources (sadly, it seems we’re no longer engineers or even people, just resources). The last few months I’ve transitioned my team into the Agile Software Development, so it’s not surprising to discover Agile-esque approaches sliding into my writing process.

In the software world, Agile is known for kicking out 100% functional, defect free releases quickly and often (plus other things that would make non-techie eyes glaze over). Think of your writing along these lines….defect free=fewer revisions, and quickly=less staring at blank page time. So how can you incorporate Agile in your writing and writing more productively? Glad you asked!

Let’s start with one of the fundamental blocks in Agile, the User Story. In the software world, the User Story is a brief sentence describing a new feature. For example, say the new feature is a Fix Me button which will correct all my computer’s problems. But that’s not very specific is it? Where does the button go and hat exactly will it fix and how will the button look…? So in Agile, the feature is written from the perspective of the customer, in a form:  As a <role>, I want <goal/desire> so that <benefit>

See how this could be used to structure your story? As a <Main Character>, I want <to find the sword> so that <I can save my best friend>

Now the trick is to make sure this User Story works, before moving forward. Once you have this User Story complete, you can forget about it* and move forward with a clear direction of where you’re going. If you take the time to define your User Story – from the big picture story, down to the scene/sequel level, your writing has purpose. And that’s the key to productivity, having clear, concise direction…

*Until revision time, of course! At that point, User Stories are help you determine why a scene isn’t working or why a chapter/character/conflict/etc. falls flat.