Why you should not make your games writers sprint
For many years, I've off-and-on enjoyed a certain glorious benefit that some people in games writing can only dream of: I've been working on teams that don't make me genuinely engage in Agile sprints.
Agile is a work management system designed for software development. Games are software, and you can't make a digital game without an engineer, so software engineering practices are dominant in games. But most studios will make everyone do Agile - or their local approximation of Agile - together. Engineers, artists, writers, everyone.
Loads of writers hate this. After all, we do not work with the same cadence, needs, or limitations as software engineers. Agile was simply not created with writers in mind.
I have special dispensation to criticize sprints and Agile for writers because I used to be a webdev producer. At that time, I was sent to an Agile training course and went on to be the producer for a group of engineers. I was the person running the sprints and the planning and scrum meetings and shit, so I'm not speaking about this from an outsider perspective.
I think the two places that Agile practices fail writers most are in sprint-related scheduling, and in its assumptions about iteration, so I'll talk mostly about that. But I'll also bring in the political and creative problems that plague games writing generally as a discipline. Games writers are usually low-status employees within their organizations, and many of the challenges they face are multiplied by the hostility and lack of support they experience.
It is not the aim of this piece to criticize Agile generally. However, by the end of this post... you may be able to guess what my opinion about it is!
Narrative can't always "sprint"
While narrative design work does often fit into Agile comfortably, the task of writing, itself, often does not.
Agile sprints are usually two weeks long. They're meant to be long enough to add a very basic version of a feature to a software development project. I've never worked at a company which did anything other than a two-week sprint cycle.
Written assets, however, are not always easy to mold into two weeks of work. A very common cadence of work in narrative would be to have one long task lasting way more than two weeks... sometimes a month or more. In my career, personally, this has been the norm. That big task is sometimes built out of a huge number of tiny, granular deliverables that may each take less than thirty minutes to write.
The long task might be a draft of the game's critical path script. It could be a draft of a set of questlines. It could also be the entire process of writing, revising, and testing a character's battle dialogue using scratch VO. The short tasks might be individual scenes, lines, or events. A lot of writing labor in games "wants" to be sliced up this way.
Splitting the big task into two-week bundles of tiny tasks is a lot harder than you'd think. The small writing tasks within big tasks are usually deeply interrelated. If I'm working on a script draft for an entire game plotline, then the closer I get to the end, the more I will need to go back and revise earlier scenes. Because the big task is one united deliverable, it's often very hard to progressively lock it in two-week chunks, or to predict which bits of the big task will be "done" in what order. It works for some games... but it's totally dependent on your game's narrative design.
On most big writing tasks, everything is "in progress" for weeks and weeks until it all suddenly becomes "done" at once. This is good, normal, and appropriate; if they get their drafts done on time and don't create bottlenecks, you should never judge a writer negatively for working this way. If you created a ticket for every scene in the game, I would expect the writer to have way more tickets in WIP at once than an engineer would ever have.
So, you sometimes gotta let the writer treat a big writing task as its own deliverable. And you gotta be willing to hire the kind of narrative leaders who can structure work within a huge deliverable like that. You need an expert who can analyze the work the writers are doing and help to choose the correct cadence for checking in and refreshing work plans. They can set the draft deadlines (we'll come back to this later... but they're gonna be setting deadlines, not sprint goals). They can develop a writer-friendly strategy for locking content progressively within a larger development plan.
One type of person who can provide that labor is an editor.
You can't ask people to iterate when the studio will punish rough drafts
Iteration is a tricky subject, too. Writing labor is often inherently iterative - drafts are iterations - so writers can work in an iterative software development framework. However, many writers refuse to share rough drafts outside the writing team. This protects them from mistreatment, but makes it much harder to do any public iteration.
Iterating adds functionality to code. Iteration adds quality to writing. These are super, super different things.
This means that the first draft of anything will probably be the lowest-quality version of it. Everyone believes themselves capable of judging the quality of writing, so writers often get extremely harsh and incompetent feedback from people who simply do not know what they are talking about. If a writer shares a rough first draft, they may suddenly find all sorts of random, panicked people from all disciplines and seniority levels swooping down on them to criticize their work - or even demanding to do some writing themselves.
Creative leaders in particular often judge writers harshly for showing real WIP assets. I have worked on games where an executive gave me line edits on an early draft script, panicking because it wasn't done yet. I've seen executives who had never written a story in their life tell me they could critique my team's work because they'd read Save The Cat. These are people who no idea what's acceptable in an early draft and what's not. They do not know when a script is "done," and they panic when they see anything that isn't final, because they're worried it will never get any better.
I've found that many writers' work practices are strongly affected by the fragility and anxiety of creative leadership. While writers in a very emotionally supportive, protected environment may be comfortable with widely sharing rough first drafts and iterating on them in the Agile process, they will refuse if they are vulnerable to coordinated attack by feral executive.
This is part of the reason why games teams should hire editors! Editors can require that all writing pass through them before anyone else sees it. They can filter feedback and talk down anxious, non-expert leadership. They can create a supportive, private, experts-only environment for early feedback, where writing can do its first few iterations without constant political challenges from everyone in the company who wishes they were a novelist.
Anyway: if you are a leader whose writers refuse to participate genuinely in an iterative work process, you might be able to solve it by deleting yourself from the situation. Hire an editor and let them manage it instead.
Why do writers have to do Agile in the first place?
Why do we manage writers with (generally poorly-implemented) Agile practices if the entire supposed philosophy behind "scrum" in particular is such a poor fit for them? It's clearly because production benefits from all workers using the same, centralized work management processes. It means that coordinating between departments requires a lot less negotiation and compromise. Or, more accurately, it permits the producers to do less negotiation and compromise. It gives them the permission to imagine that everyone in the company has the same cadences of work, that they plan in the same way - even when this isn't true at all.
I've been a producer too long to hate production for it, though. Being a good producer is very difficult! Production doesn't always get what it wants out of these processes, either - I have spent a lot of time wishing I could hit Atlassian headquarters with a nuclear missile.
But production does still benefit from all this misapplied processes and frustrating tools in a very personal way. The tools, sprint rituals, and processes that come packaged up in Agile create a LOT of documentation. And those docs make production labor visible to management.
My best producers have trusted the leaders within the narrative department to at least partially manage our own work. However, those producers then struggled to report on my work to their bosses. I've sat in more than one meeting where I showed a producer a gigantic deadline spreadsheet and watched them struggle to reframe the data in a way that would be useful to them, personally, in a performance review context. A producer needs a certain amount of gumption to go to their boss and say, "I made my team faster and more resilient by managing the writers less." But the brave ones do!
The most common way for producers to manage writers supportively is for them to create very large-scope tickets which sit in the "in progress" status for many, many weeks. Writers then exist notionally within the sprint framework, but are allowed to do their own thing... while everyone else in the company does their own fucked up headass game dev version of scrum.
No matter what, though, every single time the writers speak to production, they will still be translating between the work-tracking systems that benefit narrative - the secret deadline calendar every writing team really relies on - and the systems that benefit the production discipline.
What other kinds of products do
But what if we didn't make the poor writers do this? Having been a producer and an editor, my suggestion is that on large games with many things to track, you should just hire an editor to replace production's role in some of these processes.
Editorial is a relatively ancient discipline with its own professional standards. Editors coming from magazines, comic books, traditional publishing, and other fields will generally have what we think of in games as "producer skills" - they will have a lot of experience managing schedules, assigning tasks, approving work, and coordinating between different disciplines.
Sometimes, they will also have creative direction skills - literary editors and comic book editors, for example, completely "own" their products within the company, and may be responsible for "casting" things like a comic book with the writers and artists who create the comic. They might be responsible for setting and managing the budget for these projects. They often work directly with marketing to make sure that the product's identity, target audience, etc. are defined with their input.
I'm talking about these editors from other fields because if you're working with a games editor, a lot of them have some of this experience from another field. They may have more experience setting deadlines and shipping products than any of your producers do.
You can, if you want, completely replace your narrative producers with editors who will do production-style task tracking. But most companies would not subsequently be willing to give editors the same authority, independence, power, mentorship, or support that they give producers. Often, the best you can get in a games company is a writer who has been moved to the production discipline.
How do you track the work, then?
So let's say you have an editor or a producer with a narrative background. If you're going to discard the fiction of sprints for writers, what are you going to do instead?
You're going to have your editor set fucking deadlines! Like every other writing discipline on the planet does!
(And we'll get to this later, but I guarantee you that the writers on your team are already working to deadlines rather than genuinely engaging with the "principles of Agile.")
The big difference between a deadline and an Agile-style points-costing system is that a deadline tells the writer how much work to do on the draft. Games writing is often "functional" within the game's feature set at every draft stage (or has the potential to be functional once implemented). If you can read it, you could ship it if you had to - or at least push what you have into a build, or send a sub-par script to VO records.
Polishing game text is like baking the same cake over and over and over again - you could serve the cake at any time, but you're driven by yourself or your team to push the text quality as far as you can in the time you have available. A deadline tells a writer how much time to spend on polish.
However, producers can rarely "tell" an engineer how much work to do on a task. This is partially because not doing enough work could result in code that is straight-up nonfunctional. But it's also due to the experience and craft gap between production and engineering! This is why Agile uses points as a translation for talking about effort and time. Editors and writers do not have to use points to talk with one another - they can speak expertly about wordcount, interactivity, or quality bars. Points are a kludge for people who cannot do this.
The best deadlines are still set collaboratively - the writer stating how long they'd like to take, and the editor folding in goals from other departments. But the key part is that a good deadline gives writers a hard boundary, then also allows them the independence to move through the task in their own way. Many writers find this incredibly valuable.
Furthermore, writing is already usually done to deadlines rather than to sprints. Writing in games usually has two drop-dead deadlines: VO and localization. On top of that, narrative teams will be aware of other deadlines related to milestones, playtests, and collaboration opportunities with other disciplines.
To succeed, they need to work backwards from those dates to plan when script drafts will be due. The sprints are just a mask the deadline is wearing.
In my experience, the actual physical reality of what deadline planning looks like is almost always a spreadsheet. Even when I have a kanban board with tasks that have deadline dates on them for production visibility, I have a spreadsheet somewhere. (I'm just a freak, though.) I like spreadsheets because you can just keep adding new columns forever. You can stick as many deadlines or implementation statuses on each task as you need to. Games writers often know multiple deadlines per asset, and they sometimes know them one or even two years before they arrive.
Aren't deadlines just an evil thing they did to me in college?
I think a lot of people have personal hangups about the idea of deadlines, but it's simply a lot kinder to strictly hold writers to a deadline designed for them than it is to hold them strictly to a set of goals designed for software development.
This isn't to say that writers on games don't ever receive bad deadlines, or that an editor wouldn't ever give a writer a bad deadline - or that you won't someday hire an underperforming writer who needs constant check-ins every single morning, like a scrum meeting, to hit any deadline at all. It also doesn't mean that your team will even be good at hitting the deadlines they set for themselves! But without a software-oriented producer trying to hammer them into the wrong-shaped hole, they won't be spending extra time thinking about how to look "productive" within the sprint framework.
Their work standards will be based on the needs of your game. They will choose their biggest deadlines based on the cadence at which you plan to implement major features. They will set smaller deadlines based on the size of your game's particular type of "big tasks". They will have the opportunity to shape their own work practices based on the visibility needs of designers, artists, and engineers they collaborate with, rather than the needs of production.
I feel very stupid ending this post with just "set a fucking deadline dumbass," but it really is that simple. You are already dealing with a narrative team that prioritizes deadlines. Agile works so poorly for them that I guarantee they aren't sitting around thinking "what can I get done in the next two weeks?"
They're thinking about the next time you make them meet with the publisher, who is going to ask them: how are you feeling about the loc lock deadline? How are you feeling about the VO deadline? Everyone already knows that writers are deadline creatures.
Acknowledge what they're actually doing, and support it. And hire an editor while you're at it.