How can you define when a short story is done—and who is responsible—without complex tools?
Use a one-page definition of done to specify a short story’s delivery scope, acceptance evidence, responsibility for fixes, and who accepts its limitations. A page that opens is only a starting point: every completion claim should trace back to a specific version and check record.
Introduction
A shared document is enough to create an accountable definition of done for a short story: first establish the version being delivered, then turn content, interaction, language, and known limitations into checkable conditions. Link each condition to evidence, a person responsible for fixes, and an acceptance reviewer. Items without evidence remain pending verification, and exceptions require someone’s explicit acceptance. Only after all conditions are met can you say that this version is complete within the agreed scope.
1. Define the delivery boundary so “done” refers to something specific
“The story is finished” can mean different things to the writer, producer, and delivery lead. The writer may mean the ending is written; the producer may mean the page opens; the recipient may assume every option leads all the way through. A definition of done must first answer: which version are you delivering, what does it include, and which experiences have not been promised?
The following teaching example uses a fictional interactive short story, The Last Departure Mailbox: the protagonist finds a letter at a station and chooses either to give it to the attendant on duty or to find the recipient themselves, leading to two different endings. The characters, work assignments, defects, and handling records are all fictional. They are not a real user case, actual test results, or DramaFork product features.
Its scope statement could read: “Deliver the Simplified Chinese interactive text version corresponding to the third draft of The Last Departure Mailbox, with one entry point, one choice between two options, two endings, and a way to restart; voice acting, other languages, and resuming midway are excluded.” Give the delivery package a fixed name, and always use that name in check records.
The device scope must also identify the specific environments you plan to check; “supports mobile” is insufficient. Mark environments that have not been checked as unverified. Both the creator and the recipient must agree to the scope statement, or even a detailed checklist may end up accepting the wrong deliverable.
2. Copy this table to turn judgments into checkable conditions
Keep the work’s title, delivery version, inclusions, exclusions, check environments, and person responsible for final acceptance at the top of the document. The table below is a sample for The Last Departure Mailbox. The evidence column lists materials that should be supplied; it does not mean any checks have already taken place.
| Dimension | Completion conditions for this version | Evidence to supply | Person responsible for fixes / Acceptance reviewer |
|---|---|---|---|
| Content | Both endings explain what happens to the letter; no placeholder text remains | Node lists for both routes and locations of the ending text | Writer Xiaohe / Editor Alan |
| Interaction | Each option leads to its corresponding ending; restarting returns to the entry point and clears choices from the current run | A record of steps taken from the entry point, including the environment and actual results | Producer Adu / Editor Alan |
| Language | Body text, buttons, and ending prompts are all in Simplified Chinese; character names and forms of address are consistent | Proofreading scope, issue locations, and before-and-after revisions | Editor Alan / Writer Xiaohe |
| Known limitations | No resuming midway; leaving requires starting over, as explained at the entry point | Location of the limitation notice and a record of the recipient’s acceptance | Producer Adu / Delivery lead Xiaozhou |
Add four blank fields to every row: “Status,” “Evidence location,” “Checked by,” and “Check time.” Use only Pending verification, Returned for correction, Passed, or Exception accepted as statuses. Avoid “Mostly done,” because it does not tell anyone what to do next.
Keep each row to one set of conditions that can be assessed together. If the language item includes both unfinished proofreading and confirmed consistency in forms of address, split it into two rows instead of letting one checkmark hide the remaining work. Evidence can be document paragraph numbers, screenshot filenames, or operation records; there is no need to buy management software.
3. Walk through a decision: how evidence changes whether a delivery is accepted
Suppose that, in this teaching scenario, Alan checks the third draft against the table. The route where the letter is handed to the attendant has a complete ending, but the route where the protagonist searches for the recipient still says “Add farewell here.” Even if the page opens and the options are clickable, the content item should be returned for correction, because this version promises two endings.
Do not record only “There is a problem with the ending.” Write instead: “The final node of the search route still contains placeholder text; it should explain what happens to the letter; Xiaohe is to complete it, and Alan will review it after submission.” With the location, expectation, and next person to act specified, the team will not need to keep asking who is handling it.
Now suppose restarting only returns to the home page while retaining previous choices. Assign this item to Adu for correction. When reviewing the fix, repeat the process of making a choice, restarting, and then selecting the other option, to confirm that the old choice does not interfere with the new run. Merely confirming that the home page appears is not enough.
If time is short, the team can propose delivering a single-ending version instead. But this is a scope change: the scope statement must be updated, the undelivered option removed, and the recipient must accept the revised scope. You cannot keep the description “two complete routes” and then list the missing ending as a known limitation.
The example’s closing record could use this format: “Version: ____; evidence for content, interaction, and language, respectively: ____; accepted limitations and reasons: ____; person responsible for final acceptance and date: ____.” Blank fields mean the handover is incomplete, not that acceptance is granted by default.
4. Assign responsibility for accepting exceptions and define the limits of each role
The point of accountability is to make it possible to reconstruct decisions afterward. The person responsible for fixes resolves issues; the acceptance reviewer checks against the conditions; and the person responsible for final acceptance confirms that remaining limitations are compatible with the intended use of the deliverable. These three responsibilities cannot all be reduced to “the team is aware.”
An exception record should include, at minimum, the affected scenario, current behavior, reason for acceptance, person accepting it, and when it will be reconsidered. The lack of a way to resume midway in The Last Departure Mailbox can be a disclosed scope limitation. But if the entry point promises “Pick up where you left off anytime,” that promise must first be corrected or the capability supplied.
An unchecked item cannot be disguised as an accepted exception either. For example, if the flow has not been walked through on an agreed device, record it as pending verification. If the recipient agrees to narrow the environment scope, document the new boundary. Accepting an unverified scope and demonstrating that it works are two different records.
When working alone, you can separate production and acceptance checking into two passes, explicitly labeling the latter as self-review; this arrangement can still miss issues. A two-person team can cross-check each other’s work. For external delivery, also have the actual recipient confirm the scope. A signature cannot replace evidence and should not be understood as a guarantee of experiences that were never specified.
5. When the version changes, reopen only the affected completion items
The most common way a definition of done breaks down is that every box has been checked while the text continues to change. Whenever the delivery version changes, note the new version alongside the old record and assess which evidence remains valid. Do not overwrite the old check conclusions, or you will no longer be able to explain exactly what was accepted at the time.
Changing a character’s name requires rechecking the body text, buttons, and forms of address in the endings. Changing where an option leads requires walking through the relevant routes again. Adding an ending requires updating the content scope, interaction conditions, and supporting evidence. Change notes must identify the affected areas so the acceptance reviewer can determine the scope of rechecking.
If the work consists only of linear text, remove branch checks and retain checks for a complete ending, reading order, and language proofreading. If the work includes complex states, a one-page table serves only as a delivery summary; state and path records must also be attached. “Check two endings” cannot stand in for checking all combinations of conditions.
This definition establishes that a specified version meets the agreed delivery conditions. Whether the story is moving and whether readers want to reread it require separate feedback. You can start now with a short story approaching delivery: fill in the scope statement, write one checkable condition for each of the four dimensions, and explicitly leave items without evidence pending verification.
