A Thought On Scrum And Story Plotting

(This column is posted at www.StevenSavage.com and Steve’s Tumblr.  Find out more at my newsletter.)

As you are painfully aware, unless you have never heard of me, I’m big into applying Agile to creative methods. Writing nonfiction, however, has eluded me – but I may have had a useful breakthrough.

First, assuming you somehow didn’t know anything about me beyond my name, an explainer. Agile is an approach to projects that emphasizes adaptability, adjustment, communication, and not-overdoing. It’s most common variant is Scrum, which I practice in my career as a Scrum Master – which surprisingly is not a minor He-Man villain, but a kind of process improvement enabler.

Second, if you wonder who I am, I’m obsessed with creative improvements and development. I kinda write on it a lot – so I like reconciling creativity and Agile.

But as for taking Agile, specifically my beloved Scrum, and applying it to fiction? I’ve been challenged. First, let’s take a look at Scrum.

  • Scrum at its very basics is this:
  • A backlog of stuff ranked in order of importance – these are called Stories.
  • One takes a timeframe (called a Sprint), takes a certain amount of stuff from the backlog, and does it. Sprints are usually the same size, and usually have themes – they produce deliverable results. You focus just on the Sprint.
  • At the end of the Sprint, you re-evaluate your work, apply lessons, and do it again.

Scrum sometimes is extended in various ways. One of my favorites is “Epics” – groups of related Stories. There are also various scaling methods and so on.

On one level, you can see how Scrum may help a writer. A story is orderly sets of distinct things – events (organized into scenes). But writing is also very unpredictable; it’s certainly not a simple 2D backlog as things change. Plotting is challenging as well – with so many arcs, etc. a simple list of “write this in order” doesn’t seem to work.

This has troubled me over and over because I like writing, I like Agile, and I’m too hard-headed to give up reconciling writing and Scrum. I also want to plan my book – but I overplan it and have to back away – something Scrum could help with.

Then it hit me – this can be done. Here’s how – grab some notecards or spreadsheets.

Write down your major story arcs. There will probably be about 10-30 of them if you go into fine detail (I usually assume each character has 1-3). These are your “Features” – big bundles of events that are kind of their own tale. Think of it this way – your story “Features” several story arcs – but I’ll call them “Arcs.”

In each Arc, write down the main things that need to happen in order. Remember order – not chronology. This isn’t a timeline of “X happens in Y month,” this is a sequence. In Scrum, these are called “stories,” but for the sake of clarity, I’ll call them “Events.”

Now you have major story Arcs. In each are major Events that need to happen, which will probably either be scenes or part of a scene. Now how do you plot this out?

Simple – we use Sprints. Sprints become Chapters.

Now we have a way through.

  • Create one Sprint for each Chapter. If you have no chapters, perhaps pick an arbitrary number (I recommend ten or twenty, easy to get a percent complete). I’ll just call these Chapters.
  • Take the Arc that spans the entire tale, and sequence out its Events spread among Chapters – take your best shot and when they would happen when. Make notes as you do so.
  • Now, take another Arc and do the same – choose one of the larger ones. As you do this, you may start switching around some Events from your first effort – that’s fine.
  • Next, take one smaller Arc and place out the Events in the various Chapters – it probably won’t span the entire set of Chapters, of course. While you do this, re-sequence the Events – figure what order they happen in.
  • Finally, just do this for all of your Arcs until, adding and adjusting and rethinking. Take plenty of notes as well, scenes and inspirations and ideas are going to come to you. Also, remember, everything should be in the order of occurrence.
  • Eventually, you have a set of Chapters, containing Events, that fulfill Arcs.
  • You’ve just created an outline for your book using Agile – in a kind of mutant Scrum using different terminology, and slightly violating the idea all Sprints are the same duration (hopefully they won’t be).

By the way, note how easy it is to switch things around if you change your mind? Move one event up or down to different Chapters? Yes, very easy – because you have a rough idea of what order things happen in, but you’re not locked in – it’s all still pieces.

When you write the Chapter, then you can plot out the specific scenes. Take the particular Events, recheck their order, group them in scenes, and go. Why plot it in fine detail until you’re ready?

I used some similar ideas when plotting my current novel – but then overdid it – and as soon as I did, things felt less fun and fluid. The reason? I thought too far ahead. When I “Deplotted” it, it worked much better. Novel after this one, I’m going to try this system (unless I invent another).

Know where you’re going and in what order. But decide on the specifics when you’re ready to write them. That way, you can react to what has to be done, not have your mind three chapters ahead, and two chapters behind.

Steven Savage

An Experiment In Perspective And Productivity

(This column is posted at www.StevenSavage.com and Steve’s Tumblr.  Find out more at my newsletter.)

By now if you read my blog or my posts anywhere you know I’m kind of obsessed with Agile philosophy, Agile methods (Scrum with a heavy helping of Kanban), and I use them in my regular life. I’ve started experimenting with some of my practices and wanted to share my findings.

So first up, my basic way of being productive is a month-long sprint (a period of time where I decide what I’ll do and focus on that). With that focus I’m able to avoid distractions, measure success, and know what’s coming.

Secondly, I estimate the work I’m doing in hours, trying to break things down to manageable chunks of a few hours. My exception is writing, where I set aside an “hour budget.”

OK with that said, I began noticing a few problems I experienced. Tell me if these sound familiar.

First, as life has been complex, I felt overwhelmed. There was a lot on my plate for each month. I’d often try to “front-load” work.

Secondly, because a lot’s been going on, I was often having to shift around work and priorities. That was annoying because, yes, Agile says to embrace change for productivity, but I wasn’t feeling any gain, I was just changing. Was I wasting my time?

Third I got into a good rythm, but found myself over-focused on measuring hours and time. I was investing a lot of time in trying to measure time. This was also weird as I had things so well broken down I wondered why I fiddled with hours.

I have no doubt some of this sounds familiar.

So I sat down with myself, dived into the classic “Five Whys” method I’ve reccomended, and asked what happened. The answers became immediately apparent:

  • A month-long sprint had so much and was so broad it was unweildly and didn’t acknowledge how each week was different, and it was hard to change.
  • My estimates in hours were “too real.” Thinking of things as hours led me to spend too much time trying to map “real time” as opposed to getting stuff done. So I was actually less efficient because of asking “is this an hour or not.” Another reason the whole Scrum “points thing” makes sense.

So now I’m experimenting with a few changes to help me be productive and also lighten me up a bit.

First, I’m now doing classic two week sprints (Monday to Monday). This takes me out of monthly thinking, focuses on a smaller time frame so I can better evaluate what I should do, and makes it easier to adapt. This has already been a godsend in focus.

Secondly, I’ve – yes – ditched time estimates and Fibonacci points. Because I’ve gotten really good at breaking work down, I’m now just treating everything as “things to do” and breaking them down to the smallest components. For things like writing, I’m giving myself “X writing sessions” each sprint to sit down and write. Then I just check off “done.”

I’ll let you know more about my findings (and I may need to update my Personal Agile book).

However, I do want to answer an unspoken question: do I regret my earlier productivity techniques, with month-long sprints and so on? No.

What I did worked for the time. It got things done. It also let me learn so I could keep improving what I did. It may even be that worked then but I had to find a different way to do things now.

It’s OK to change how you operate and get things done. Doing things is how you learn to do them better.

Steven Savage

My Personal Agile: Visualization

(This column is posted at www.StevenSavage.com and Steve’s Tumblr)

So you’ve just started your own sprint.  You’ve got a nice big spreadsheet.  You may like that (I do) but if you’ve done any agile research you may ask:

“Why the heck are we doing this in a Spreadsheet?”

There are a lot of tools for organization and time management: Trello, Smartsheets, and my beloved Rally.  Why aren’t I using them here?

A few reasons – none admittedly all that noble.

  1. I am deliberately avoiding more sophisticated tools right NOW because I want to perfect my process.
  2. Spreadsheets give me a lot of control and I can read them with multiple kinds of software.
  3. There’s a lot of choices for tools, but none quite my style – or that I want to pay for.
  4. I track things down to very fine levels – these tools might overdo my breakdowns or it’d take more work to use them.
  5. I am used to operating out of spreadsheets.
  6. I compensate for the limitation with some other methods, some of which I list below.

But some of us don’t work out of spreadsheets.  Why?  We need visuals.  I’ll present you some ideas, but a note:

In “professional” practice of Scrum, I use the big visible boards either automated or printed out, and track to the task level on most teams, the story level on teams of specialists.  What works here may work for you and not work for a team or vice versa.

For instance, one tool may work for a team and not you.  My spreadsheet method would be a disaster for a team in most cases.

Anyway, let’s talk about ways to visualize your work if, like most people, you don’t love spreadsheets like I do:

Solution #1: Use One Of the Tools I mentioned

Trello, Rally, and so on.  Really requires you to learn and adapt to one of them.  It could work, but you’d have to learn a new tool.

The plus side is it may work and you learn a tool to use elsewhere.

Solution #2: Pivot Tables

Since all my work is in a spreadsheet, I use pivot tables and quick calculations to see where I am story wise, figure how much work is done, etc.  After doing this for nearly a year I had pretty good instinctive sense of where things are.

As a note, I do create a rough “guess” every week as to what I can, will, and have to do and look at that separately.

Solution #3: Print Out Your Sprint Backlog

This is a cheesy but surprisingly effective way to track work – Print the backlog out.  Tape it on a wall or something.  As work moves, fill in the spreadsheet cells, using them to track progress.  If you use it well, you might not even need to update the original spreadsheet (though I do as I like to run a lot of statistics)

I did this for awhile, by the way.  It helped, but really as I was always in the Spreadsheet I didn’t need it eventually.

Solution #4: The Big Visible Board

A lot of Agile methods – especially Scrum and Kanban, use a Big Visible Board.  You take some board, divide it into columns for the different categories (Backlog, Defining, Developing, Review, Done), and then stick notes or cards up for each task or story, and move those around.  Yeah, it’s nothing more than cards or sticky notes on a board that you move around.  But it’s fast, easy, and in-your face so you’re aware of what’s going on.  It also helps teams coordinate because they get to see what’s up at a glance.

Now you’re not a team, but these Big Visible Boards help you stay focused – you see it all the time, you’re aware of it.  If you find operating out of a spreadsheet doesn’t work I recommend trying this method.

However, my guess is that if you look at your Sprint Backlog there’s a lot there.  A few Projects, a good amount of Stories, and a lot of Tasks.  Wouldn’t the board get overwhelming?

Well first, if it’s overwhelming maybe you’re overloaded.  But if you’re not, here’s a few recommendations:

  1. Only have Defining, Developing, Review, And Done on the board.  Put your print-out Sprint Backlog on the left.  As you take tasks, make sticky notes for them on the board and see them through.  Sure you get a pile of sticky notes at the end, but that gives you a sense of progress.  By the way, you probably won’t need to update the original spreadsheet much if you do this.
  2. Track by stories.  This is a bit more challenging, but if you’re REAL focused on doing each story all the way through before you take on another, then you can just track on the story level.  Put the tasks on the story and check them off as you do them.  By the way, if you have good story/task breakdown you may have to combine it with method #1.
  3. Two-board solution. On the top are the stories in progress.  On the board below, active tasks.  Might get confusing, but it could help you get “both” levels.

Again, see what works for you.  but that’s the point – what works for you.

– Steve