In my latest Scrum for Writers post, I write about continually improving my writing process with the Sprint Retrospective.
Scrum
Scrum for Writers: Sprint Review
Using Scrum for writing fiction means reviewing the work every Sprint and adapting my story plan. Here’s how I do it.
Scrum for Writers: The Scrum Board

It’s not easy to see how all the pieces fit together when using Scrum for writing. This week, I pause my exploration of the mechanics of Scrum to elaborate on how the Goals and Backlogs can be made visible in “Using a Scrum Board for Writers.”

Scrum for Fiction Writers
I continue to explore using Scrum for writing fiction.
Crafting a Product Goal will help keep you focused throughout the duration of creating your work.
Once you have a Product Goal, you can use it to develop your initial Product Backlog.
With a Product Backlog in place, plan your first Sprint and then check in on your Sprint progress every day with a Daily Scrum.
Coming soon: Sprint Review and Sprint Retrsopective!
Replacing the Outline with a Product Backlog
For the past year or so, I’ve been using the principles and practices of Scrum to manage my writing. The most valuable change has been to adopt a Product Backlog as a middle ground between a detailed outline and total seat-of-the-pants plotting. In my latest Medium piece, I describe how it works.
Does Scrum have too many meetings?
One of the most common concerns I hear about Scrum is, “There are too many meetings.” I dig into the origins of that complaint in this week’s Trainer Talk podcast.
Solvable
I have a deck of journal prompts my wife bought me. The card I drew today asked, “Think of a situation that’s currently got you stumped. How would one of your heroes resolve it?” And I thought, I’m not stumped by anything right now. It’s not that I know how to resolve every problem in my life; I don’t. But I believe that all my problems are solvable even if I can’t see the solution right now.
This outlook grows out of my career as a Scrum Master and an agile coach. The purpose of Scrum is to solve complex problems. The solution to a complex problem is unknowable in advance. You have to experiment your way to success, and success is not guaranteed, easy, or obvious. You fail a lot. You learn from the failures.
I’ve been using Scrum for my own life goals for over a year now. Every week is a Sprint, and every Sprint is an experiment. I experiment with writing techniques. I experiment with improving my health, both physical and mental. I experiment with different ways to improve my performance at work. I’ve come to believe that there are few personal problems that can’t be solved, if you refuse to stop looking for a solution.
Agile Coaches’ Corner Episode 63: Tips for New Scrum Masters
This week, I filled in as host of the Agile Coaches’ Corner podcast. My guest, Adam Ulery, talked about tips for new Scrum Masters. Check it out!
LEGO play date
At last night’s Tampa Bay Scrum Master’s Guild, we did a simulation of a scaled Scrum project. We used LEGO bricks to build the components of a zombie defense system. It was fun, of course. How can LEGOS be anything but fun?
At one point, when several members of my team were off coordinating with other teams, my friend Jessica and I remained at our table. As we caught each other up on what we’ve been doing since we last saw each other, we idly assembled pieces of our teams design. It was very relaxing to be engaged in what amounts to children’s play while we talked of the challenges of adult life. Maybe, the next time we arrange to get together for coffee, we should bring a bucket of LEGO bricks to play with, too!
Roll your own Daily Scrum
Yesterday, Scrum.org released an update to the Scrum Guide, with mostly minor changes to Scrum practice. The new guide clarifies that Scrum is for delivering complex products (rather than being limited to software), refines the Scrum Master role, and clarifies that Scrum events time boxes are maximum lengths. It also states that each Sprint Backlog “includes at least one high priority process improvement identified in the previous Retrospective meeting” in order to foster continuous improvement. That has been a common practice for many Scrum teams, and it’s a welcome addition to the guidance.
To me, the most significant change was to the description of the Daily Scrum. Previously, the Guide mandated that participants answered three questions to examine the team’s progress toward the Sprint Goal:
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
Those questions are still provided, but instead of prescribing them as the specific, required practice of Scrum, they are only an example of how a team might inspect and adapt its plan to complete the sprint goal.
This is a big deal. The Guide states that “Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.” Prior to this update, if you were doing something different in the Daily Scrum, technically, you weren’t practicing Scrum. In some case, it led to rigid, stale Daily Scrums that were more like a classic status report.
Now teams may be more likely to experiment and find the practice that is most useful to them. Early in my Scrum Master career, I had a team that twice modified the Daily Scrum to suit its needs quite dramatically. The first time, they did away with the “What did I do yesterday” question. No one found that valuable. The Scrum Board showed that quite clearly, and they wanted to spend more time talking about what they would do that day, and what impediments were likely to get in the way.
Later, they realized that answering the questions in turn led to confusion, because it presented the progress of backlog items in an out-of-sequence manner that made it difficult for them (and for the Product Owner) to understand. Instead, they switched to a “walk the board” process. They would look at the highest priority item on the list, and talk about what was necessary to complete it. What was the next task to do? Who would do it? Did anyone need any help? And then we went to the next one on the list, and so no, until they’d accounted for each backlog item in progress.
Neither of these practices were technically Scrum, because the guide prescribed a different practice. But both changes made the team more productive, and helped them achieve sprint goals with greater ease and speed. I’m glad to see that the Guide now welcomes this kind of innovation.