Direct answer: inventory every approved master asset, give it one stable Asset ID, assign one editing owner, define the exact derivative to produce, name its proposed publishing use and record the handoff state. Split work by observable output rather than by vague labels such as “my half” and “your half.”
A finished collaboration can still produce a messy handoff: twelve clips, two editors, three creator pages and no shared answer about which crop belongs where. The shoot may have gone smoothly while the useful footage remains trapped in camera-roll names and duplicated edit requests.
This worksheet starts only after the usable collaboration assets are approved for planning. It assigns editing workload and proposed uses. It does not establish ownership, consent, compensation, provenance or publishing permission, and it does not replace the records that handle those decisions.
Start with assets, not an equal-looking split
“Creator A edits half” sounds fair but does not define a deliverable. Five short clips may require more decisions than one long master. A useful split describes each production job: source asset, selected time range or frame set, target format, finish standard, owner and destination.
First reconcile the asset inventory against the completed shoot. The collaboration tracking sheet can hold the collaboration-level record; the asset-split worksheet begins at the smaller unit of one approved master or one clearly bounded segment.
Do not split a folder merely by file count. Record duration, shot changes, audio condition, edit complexity and required derivatives. Those facts make the workload visible without pretending that every minute of source footage demands the same effort.
Create one stable Asset ID per approved master
A stable ID lets both creators refer to the same material when local file names differ. Use a short collaboration code, shoot date and sequence number, such as COL-JUL30-04. Keep that ID attached to the unedited master and to every derivative made from it.
The content asset naming system provides the broader file convention. In this worksheet, the ID is the join key: it connects the source inventory, edit job, review note and delivered derivative without copying entire folders into every row.
If one long recording contains three independent scenes, retain the master ID and create bounded child jobs such as COL-JUL30-04-A. The parent relationship must stay visible. Otherwise two editors may cut the same moment under unrelated names and nobody can reconcile the versions later.
Separate the master, cut and publishing-use fields
The master field answers “where did this come from?” The cut field answers “what transformation will be made?” The proposed-use field answers “where might this finished derivative fit?” Combining all three in a note makes status hard to audit.
A proposed use might be paid-page feed, preview, promotional vertical cut, still selection or archive-only. It is a planning label, not publishing approval. A creator can change or remove the proposed use while the edit job remains valid.
One master can have several derivatives. Give each derivative its own row or sub-ID, because a square preview, vertical teaser and long edit have different crops, captions and quality checks. The master is not “done” simply because one derivative exists.
Describe the edit as a testable output
Replace “make it good” with an output specification: selected range, aspect ratio, framing instruction, audio treatment, colour reference, overlay requirement, maximum preview exposure and export format. Include only requirements already decided for the collaboration.
An editor should be able to mark the job ready for review without guessing what completion means. If the output cannot be checked from the row and linked reference, the assignment is still a conversation rather than an operational job.
Record exclusions too. “No on-screen text” or “do not use the final scene in the preview” prevents an editor from creating an otherwise polished derivative that cannot serve its intended role.
Allocate workload using effort bands
Use creator-defined effort bands rather than universal time estimates. A light job could be a trim and export from a selected range. A medium job could require reframing, sound cleanup and a review pass. A heavy job could involve multiple source segments, continuity work or several derivatives.
The bands exist to balance the queue, not to price labour or judge skill. Two creators can calibrate the bands against their own editing setup. If the first pass reveals a job is materially different from its band, update the evidence and rebalance remaining work.
Also count coordination load. The person assembling final exports, collecting review notes or reconciling file versions is doing visible work even when they are not cutting footage. Give those handoff jobs owners rather than leaving them as invisible shared responsibility.
Assign one owner and one reviewer
Each derivative needs a current editing owner. Shared ownership usually means neither person knows who should act next. A separate reviewer can confirm the output matches the row, but the reviewer should not silently rewrite the assignment.
If the owner changes, record the handoff date, current version and remaining action. Do not erase the earlier owner; the history explains why a file exists in two workspaces or why an intermediate export was abandoned.
Use the post-production asset handoff checklist when a job moves between people or into final storage. Return the handoff evidence to the worksheet as a reference, rather than pasting a second checklist into the row.
Use a small set of production states
Backlog means the job is defined but not started. Editing means the owner has an active working version. Review means a candidate export exists. Changes requested means the review names a specific correction. Ready means the derivative passed the defined output check. Handed off means the finished file and context reached its recorded destination.
A job has one current state. Notes such as “nearly ready” are not states because they do not specify the remaining evidence. When a review finds a mismatch, return the row to Changes requested with the exact version and correction.
Keep publishing separate. Ready or handed off does not mean posted. This worksheet can name a proposed use, but it should not imply that the later publishing decision occurred.
Copy the collaboration asset-split worksheet
Practical artifact: create one row per derivative job, retain the master relationship and total the creator-defined effort bands before confirming the split.
| Field | What to record | Completion evidence | Example |
|---|---|---|---|
| Asset / derivative ID | Stable master ID plus child job | Matches inventory and file label | COL-JUL30-04-B |
| Edit output | Bounded transformation and export | Candidate can be checked against specification | Vertical preview from selected range |
| Proposed use | Planning role, not approval | Use is named or marked undecided | Creator A promotional draft |
| Effort and owner | Local effort band, editor and reviewer | One current owner and next action | Medium / Creator B / Creator A review |
| Version and state | Working version, current state, handoff reference | Timestamped transition evidence | v2 / Review / export link |
Walk through a fictional split
Two creators finish with four approved masters. Master 01 needs one long edit and one preview; Master 02 needs still selections; Master 03 needs two vertical cuts; Master 04 stays archive-only. That is six derivative jobs, not four equal files.
Creator A takes the long edit and still-selection job. Creator B takes the two vertical cuts and preview. The archive job has no edit owner because no transformation is planned, while the handoff owner is named separately. The split becomes reviewable without claiming that both sides performed identical tasks.
During review, the preview is found to expose a moment excluded by the brief. Its state returns to Changes requested and only that derivative is revised. The long edit can continue to Ready because each output has its own row.
Reconcile the board before closing it
At close, every approved master must appear as a derivative job, deliberate archive-only row or documented exclusion. Every active job needs one owner, one current version and one observable next action. Every Ready row needs a check result.
Compare expected derivatives with delivered files. Duplicate names, missing parent IDs and unexplained extra exports are reconciliation defects. Resolve them before moving the collaboration folder into long-term storage.
Keep the worksheet with the collaboration record so a future content planner can understand why a file exists and what role was proposed. Do not treat old proposed uses as permanent instructions; they are dated planning context.
Method sources
The official Scrum Guide, released in November 2020, supports transparent work items, accountable ownership and inspectable increments. This worksheet borrows those general visibility principles but is not presented as Scrum.
GOV.UK governance principles for agile service delivery, published February 22, 2016 and updated May 23, 2016, supports timely decisions and lightweight evidence. SirenCY created the asset-level split method for this creator workflow.
Limitations
Limitations: this worksheet allocates editing tasks and proposed publishing uses only after the source set is approved for planning. It does not establish ownership, consent, compensation, provenance or publishing permission, and a completed row does not authorise publication.
Effort bands are local planning labels, not universal time standards. File duration and derivative count cannot reveal all creative complexity. Re-estimate when the actual source condition or requested output differs from the recorded evidence.
The worksheet cannot prevent lost files, conflicting offline copies or unrecorded changes. Pair it with stable storage, versioned handoffs and creator review. A neat allocation is useful only when the referenced assets remain available and the state is kept current.