Estimate a Pilot’s Running Time from Scenes, Not Page Count
Estimate a Pilot’s Running Time from Scenes, Not Page Count
A page is not a unit of time. It is a unit of paper.
Two pages can hold a man crossing a city in eleven shots, or one line of dialogue and a long look at a closed door. Same page count, wildly different screen time. Multiply your pilot’s page count by a minutes-per-page figure and you have converted paper into paper and called the result a schedule.
The alternative is slower and far more useful. Work scene by scene. List the things that actually consume time. Price each one and write down where the price came from. Then draw them on a timeline so you can see which of them run together. What you get is a provisional timing model you can test against a read, a rehearsal or an assembly — not a promise of what the pilot will run.
Break the dated script into things that take time
Start by writing the script’s version and date at the top of your table. Every number underneath belongs to that version. When the draft changes, the numbers stop applying, and if you have not dated them you will spend an afternoon wondering why your total moved.
Then go through the scenes and list what eats time:
- Spoken passages. Not “dialogue” as a lump — the individual speeches, plus any line where two people talk over each other.
- Actions. Crossings, door openings, bag zips, car starts, the business that carries a scene physically from one state to another.
- Holds. Silences that are doing work. A look, a pause before an answer, someone deciding.
- Transitions. Entrances, exits, scene changes, anything between the last beat of one scene and the first beat of the next.
For each entry, mark whether it exists in the script or whether you are supplying it. “She exits” is written. “She exits and takes four seconds to cross the room” contains an assumption. Those are different columns and they should never be the same column.
This is where page count collapses. A two-line montage description — The city wakes. He rides the bus. Construction crews. The building. He stands outside. — may contain nine separate actions and a music cue, and can run longer than a dense page of fast overlapping dialogue. Nothing on the page tells you which page is heavier. Only the list does.
And when something is genuinely unclear — a fight, a crowd, a piece of choreography you cannot yet picture — write “unknown, needs rehearsal” in the cell. A visible gap is worth more than a confident number you invented to fill it.
Time a plausible performance, then label the assumption
For a spoken passage you have two honest options. You can read it aloud and time it, or you can count the words and apply a delivery rate you have chosen. Say which one you did, because they are not the same kind of evidence. A read is at least a real performance of the text, by one person, once. A rate calculation is arithmetic.
For action, the question is what the movement requires: how many steps, how many objects, how far, whether anything resists. Ten seconds of “she crosses to the window” is an assumption about room size, walking speed and whether she stops on the way.
Jennifer Carriere, writing on Stage 32 about how she preps as a script supervisor (checked 2026-09-13), describes timing imagined dialogue and action with a stopwatch, recording scene estimates, and later comparing those estimates against actual scene timings. That is the useful shape of the practice: estimate, record the basis, compare later. What her published example shows is timings added one after another — a sequence. Keep that in mind, because the next section asks a question the additive example does not.
A limitation worth stating plainly: a fast table read tests dialogue delivery. It does not test picture. There is no staging in it, no travel time, no one hauling a bag, no music, no cut. If your pilot is action-heavy, a read is a partial measurement of one component. Treat it that way rather than as an audiovisual timing test.
Put simultaneous events on one timeline
Write each entry as an interval with a start and an end, relative to the beginning of the scene. Now you can see when things happen, which is exactly what a total cannot tell you.
Here is a hypothetical scene to work with. It is invented, and the numbers in it are assumptions rather than measurements — I’ll mark that as we go.
NIGHTSHIFT — Draft 3, dated 12 March. Scene 14. Laundromat, night. NIA: “You said you’d call Thursday. It’s Thursday. I sat in that parking lot for two hours with your jacket on the passenger seat. You didn’t.” Theo says nothing. Nia pulls a duffel bag off the folding table and zips it shut. Nia exits through the back door.
Twenty-five words. At a chosen pace of about 125 words per minute, that is 12 seconds. The pace is an assumption, not a reading — I have not timed anyone saying it, and neither has anyone else so far. The bag business is estimated at 20 seconds. The exit, 4 seconds. All three are estimates.
Staging A — sequential. Nia finishes speaking, then moves, then leaves. Nothing overlaps.
0 1 2 3
0123456789012345678901234567890123456
speech [==========)
action [===================)
exit [===)
Speech runs 0–12, action 12–32, exit 32–36. Total: 36 seconds.
Staging B — early start. Nia starts dragging the bag at second 4, while she is still talking. The action still takes 20 seconds; it just begins earlier.
0 1 2
0123456789012345678901234567890
speech [==========)
action [===================)
exit [===)
Action runs 4–24. The exit, still sequential, runs 24–28. Total: 28 seconds.
The whole difference — eight seconds — comes from a specified staging choice. Not from a discount, not from a fudge factor, not from “subtract 20% for overlap.” Notice how much better that is. If you disagree with the eight seconds, you can point at the busiest part of the drawing and tell me the bag work would actually be slower if she were talking through it, or that at second 4 she hasn’t reached the bag yet. The argument stays concrete.
That is the failure mode of a vague overlap allowance: it reduces a total by some percentage of a number that never said when anything occurred. You cannot audit it, reproduce it or learn anything from it.
Build alternative estimates from named staging choices
A scene you cannot yet picture needs more than one version. Keep them separate and name them after the thing that differs, so a later reader knows what they are choosing between.
For Scene 14:
| Version | What differs | Scene elapsed |
|---|---|---|
| Sequential | Nothing overlaps | 36 s |
| Compact | Action starts at 0:04, during speech | 28 s |
| Sustained | Action starts at 0:10; Nia holds three seconds at the door before exiting; exit still 4 s | 37 s |
The sustained version runs 10–30 for the action, 30–33 for the hold, 33–37 for the exit. Note that the hold is not in the script. It is a staging assumption, marked as one, and it makes the sustained version longer than the purely sequential baseline. Compactness and overlap are not the same idea. Adding a pause adds time even when other things run together.
Do not average these. The midpoint of 28, 36 and 37 is a number nobody has proposed. It corresponds to no staging choice, no performance and no script. Print all three, or pick one and say why — averaging three incompatible plans into one figure is how a timing model becomes a horoscope.
Two clean-up checks while you are here. First, every element should appear exactly once. Transitions, opening material, titles and any “previously on” have a habit of getting counted inside a scene and again in a separate line. Second, record what your estimate leaves out. Music sequences with no specified duration, an unresolved montage, a fight you haven’t choreographed — name them below the total so the total’s limits travel with it.
A roll-up looks like this, and it is important that it looks unfinished:
| Scene | Status | Compact | Sustained |
|---|---|---|---|
| 14 | estimated, Draft 3 | 28 s | 37 s |
| all others | not yet estimated | — | — |
That is not a pilot estimate. It is the shape of one, with one honest cell filled in. Which is the point: your running total should show its own gaps rather than rounding them away.
Use the discrepancy to revise the model
Later, when you have a timed read, a rehearsal or an assembly, put the observed result next to the assumption that produced the estimate. Then name what changed.
“The scene ran 31 seconds, not 28” tells you very little. “The speech took 15 seconds, not 12, because the third sentence kept getting a beat in front of it” tells you where the model was thin. So does “the bag work ran 26 seconds, not 20 — the estimator had never handled a duffel that full.”
Keep dialogue-only observations separated from screen time. A read tells you how long it takes to say the words. It does not tell you how long the scene holds, because nothing has been staged and nothing has been cut. When an assembly finally exists, its runtime includes editorial decisions that no script estimate can contain, in either direction. A scene can shrink by a third in the edit and a different scene can double. Neither outcome means your method was wrong; it means you learned something about which assumptions matter.
Last thing: revise the script version and the assumptions together. If Draft 4 adds a page to Scene 14, the Draft 3 numbers do not migrate. They stay attached to the dated table they came from, and you build a new one. A timing model whose numbers can’t be traced to a version is not a model, it’s a rumor.
Where the estimate stands, and what to time next
End the exercise with something specific enough that someone else can challenge it.
Nightshift, Draft 3, dated 12 March. Scene 14. Compact staging: action begins during the speech, exit follows sequentially — 28 seconds. Sequential staging — 36 seconds. Sustained staging, with an unwritten three-second hold at the door — 37 seconds. The dialogue component was never read aloud; that is the largest open assumption in all three figures.
Next passage to time: the first read of Scene 14’s dialogue, out loud, with a stopwatch. That single reading will replace one column of guesses and leave the bag work and the hold exactly as uncertain as they were — which is a useful thing to discover early, before you have built a whole pilot on the assumption that a read settles everything.
Keep the drawing next to the numbers. The numbers tell you how long. The drawing tells you what you assumed in order to get them, and that is the part worth arguing about.
Frequently asked questions
Why can two scripts with the same page count run to very different lengths?
A page is paper, not time. Two pages can contain a multi-shot city crossing or one line and a long look at a closed door. Multiplying page count by minutes per page turns paper into paper; a scene-by-scene list of what actually consumes time is the useful alternative.
What should be listed when breaking a script into time?
List spoken passages, including overlapping lines; actions that move a scene physically; holds that do work, such as silences or decisions; and transitions such as entrances, exits and scene changes. Mark each entry as written in the script or supplied as an assumption, and mark genuinely unclear material as unknown, needs rehearsal.
How should simultaneous or overlapping action be estimated?
Write each entry as an interval with a start and end relative to the scene's beginning, then draw them on a timeline. This shows what overlaps and when. Keep named staging versions, such as sequential, compact or sustained, separate rather than averaging them; an average may correspond to no proposed performance.
What does a fast table read actually test?
It tests dialogue delivery. It does not test picture, staging, travel time, handling objects, music or cuts. If a pilot is action-heavy, a read is only a partial measurement of one component, not an audiovisual timing test.
Why keep the script version and date attached to every estimate?
Every number belongs to that version. When the draft changes, the numbers stop applying, and undated totals become confusing. Estimate assumptions and script version should be revised together; numbers that cannot be traced to a version are not a model.