If you’ve replaced your outline with a Product Backlog and you have refined some “ready” items, you may be wondering what to do next. How do you balance writing with adapting your Product Backlog? The answer is to use Scrum’s cycle of events, called a Sprint. And the Sprint begins with Sprint Planning.
A Sprint is a short period of time in which you set a short-term goal and focus on completing it. For me, one week is the right cadence. Work obligations and my personal life throw enough curve balls that I can’t accurately assess how much time I’ll have for writing beyond that horizon. Your mileage may vary, but shorter is better. Short sprints reduce complexity and allow you to respond to change with more flexibility.
Each Sprint begins with Sprint Planning. For one-week Sprints, I need about an hour. If you use a longer Sprint, you’ll likely want to set aside more time — enough to think through these three topics:
· What is my goal this Sprint?
· What Product Backlog Items will help me achieve that goal?
· How will I work on them?
What is my Sprint Goal?
The Sprint Goal is a step toward the Product Goal. In the same way that the Product Goal guides the emergence of the Product Backlog, the Sprint Goal guides the emergence of the work you’re going to do this Sprint, AKA the Sprint Backlog.
The Sprint Goal should be specific enough to guide you but also leave room to adjust the scope you select as new information emerges. I like to use the SMART goal formula: Specific, Measurable, Achievable, Relevant, and Time-Oriented.
Here are some examples of Sprint Goals for my current novel:
· At the beginning of the story, when there was a lot of uncertainty: Introduce my protagonist and her fiancée.
· After a few Sprints, when the story had found its legs (and my protagonist had found a name): Hope discovers evidence that her fiancée lied about his past.
· Much later, when the story was well under way: Hope finds a key piece of evidence that police have overlooked.
Note that I avoided things like, “Write three scenes” or “Finish Chapter 5.” Goals like that are simultaneously too vague and too restrictive. Too vague because there aren’t any details about how I expect the plot to unfold, and too restrictive because I don’t know that I’ll write a specific number of scenes or a full chapter.
Creating a Sprint Goal usually takes me about ten or fifteen minutes of reviewing my Product Backlog and my progress to date, then and freewriting about what I want to accomplish. I don’t sweat making it perfect because I might revisit it in the next step.
What Product Backlog Items will help me achieve that goal?
With a Sprint Goal in mind, I turn to selecting the items in my Product Backlog that will support that goal. Typically, I’ll select the top several items, but occasionally I’ll realize that I need to skip one near the top and go a few items deeper. That’s OK! The order of the Product Backlog is only a best guess at the time you refine it.
How many items I choose depends mostly on how much time I’ll have that week. I typically can only devote 14 hours per week. That’s enough for 4–5 ready Product Backlog Items. Naturally, I’ll shrink my expectations when obligations or distractions will cut into my time. And I select more work when I have a company holiday or a weekend of rain in the forecast that will give me more time.
A second factor that can affect how many items I select is how well I understand the Product Backlog items I’m selecting. If I haven’t had time to refine, or new story details have emerged that require a lot of thought, I’ll select fewer items.
Sometimes, as I select PBIs, I discover that I need to adjust your Sprint Goal. I don’t finalize it until the end of Sprint Planning.
How will I work on the PBIs I selected?
Once I’ve selected the PBIs for my Sprint, I’ll make a plan for each of them. What tasks do I need to do? How long do I expect them to take to write? I estimate in number of writing sessions I think I’ll need. That allows me to sum the estimates and compare them against how much time I think I’ll have this week and make sure I haven’t planned too much to do. Here’s an example PBI from a Sprint for an older project:
Scene: Greer goes to her client’s house
· Greer wants to find Hazel before the killer does.
· Hazel doesn’t answer her phone.
· Hazel doesn’t come to the door when Greer knocks.
· Hazels’ neighbor tells Greer that a man who looks like the killer was there 30 minutes ago.
Those bullet points are likely details that I worked out in refinement. They usually feed the tasks. For this item, the tasks were:
· Task: Greer starts driving and calls Hazel from the car. Direct to Voice Mail. Leaves message: Go somewhere public w. lots of people, call me, ID of killer. 1 session.
· Task: Greer arrives at Hazel’s. Describe house. Yard unkempt, mail in box. Neighbor outside. 1 session
· Task: Describe neighbor. Retired. Sour face. Does Not Approve of anything he sees. 1 session
· Task: Greer knocks, no answer. Asks neighbor when he last saw Hazel. 1 session
· Task: Conversation with neighbor. Hazel was stringing 2 men along. One matches killer’s description & was here until 30 minutes ago. 2 sessions.
The last one is two sessions because I know I have trouble with dialog, and I’ll need extra time to work it out. I use an iPad app called Cardflow+ to lay out note cards on a virtual whiteboard, as shown here:
Sprint Planning helps me look at the big picture of what’s left to complete my story and then focus on what I can do in the short term to get closer to finishing. I have a goal that helps me steer the story — and adjust my plan — as I discover things about my story during the Sprint. How I make those day-to-day adjustments will be the focus of my next piece: “The Daily Scrum.”