Crates: Loading Work Into Flights

If flights are the strategic container - the "what are we trying to accomplish" - then crates are the tactical units inside them. Each crate represents a discrete piece of work that needs to happen for the flight to land. Think of them as cargo being loaded onto the airplane: individually packaged, clearly labelled, and ready for delivery.

What Are Crates?

A crate is a single deliverable within a flight. It might be a feature, a bug fix, a design asset, a documentation update, or anything else that contributes to the flight's objective. Crates are intentionally simple - they have a title, a description, a link to your issue tracker, and a status (done or not done).

The simplicity is the point. Traditional agile artifacts like user stories come with a template ("As a [user], I want [feature], so that [benefit]"), story points, acceptance criteria, definition of done, and often a dozen custom fields bolted on by well-meaning process enthusiasts. Each of these additions creates friction. Each one is another thing to fill out, debate, and maintain.

Crates strip all of that away. A crate says: "Here's a piece of work. It's either done or it's not." The nuance, context, and acceptance criteria live in your issue tracker where they belong - in the GitHub issue, the JIRA ticket, or the Linear card that the crate links to. The crate itself is just the flight-level view of that work. If your organisation has connected GitHub or JIRA in Settings, you can search and link issues directly when adding crates - no copy-pasting URLs required.

This design means crates are fast to create, easy to understand, and low-maintenance. You're not fighting with a template or agonising over whether something is 3 points or 5 points. You're loading cargo onto the plane and keeping track of what's been delivered.

Crates vs. Tickets

This is one of the most important distinctions in the Flights methodology, and it's worth being very clear about it: crates are not a replacement for your issue tracker. They work alongside it.

Your issue tracker - whether that's GitHub Issues, Linear, Jira, Shortcut, or a spreadsheet - is where the detailed work lives. It's where you describe the implementation, track sub-tasks, have technical discussions, attach mockups, and manage the granular workflow of individual pieces of work.

Crates provide the flight-level view. They answer the question: "What work is in this flight, and how much of it is done?" Each crate links to one or more items in your tracker, creating a bridge between the strategic (flight) and tactical (ticket) levels. You get the best of both worlds - detailed task management where you need it, and high-level progress visibility where you need that.

This layered approach means you don't have to rip out your existing tools to adopt Flights. Keep using whatever tracker your team is comfortable with. Crates sit on top, providing the organisational structure that connects individual tickets to team-level initiatives. It's additive, not disruptive.

Teams that try to use crates as their primary issue tracker typically find it too lightweight - and that's intentional. Crates are designed to be the summary, not the spec. Keep the detail in your tracker, keep the overview in your flight.

Loading Crates

Crates can be loaded onto a flight at any point - during takeoff planning, mid-flight, or even just before landing if a last-minute piece of work emerges. The flexibility is important because real projects rarely follow the plan exactly. New requirements surface, priorities shift, and scope evolves as the team learns more about the problem.

That said, the bulk of crate loading should happen during the takeoff phase. This is when the captain and crew sit down - briefly - and identify the major deliverables for the flight. Each crate should represent a meaningful chunk of work that contributes to the flight's objective. Too granular and you'll drown in crates. Too coarse and you won't have useful progress visibility.

A good rule of thumb: each crate should be completable within the flight's duration and by a single person or pair. If a crate will take the entire flight to complete, it's probably too big - break it down. If a crate can be done in an hour, it's probably too small - bundle related work together.

For a typical two-week flight with three crew members, you might have 8 to 15 crates. That's enough granularity to show meaningful progress without creating a management overhead. The captain can glance at the crate list and immediately know where things stand.

When loading crates mid-flight, the captain should communicate the scope change to the crew and, if necessary, to stakeholders. Adding crates increases the flight's scope, and if the landing date doesn't change, something else might need to be deprioritised. This trade-off should be explicit, not silent.

Tracking Progress

Progress tracking in Flights happens at two levels - and that's intentional. The detailed, task-level tracking lives in whatever external system your crates link to. GitHub issues have their own status. Linear tickets move through their own workflow. Jira cards do their Jira thing. That's where granular progress belongs.

At the flight level, progress is simpler. The flight's status tells you where the initiative stands - is it preparing for takeoff, actively in the air, hitting turbulence, or safely landed? That status, combined with the landing date, gives everyone the picture they need without anyone running a report.

This two-layer model means you don't need to duplicate tracking. The detail lives in your tracker, the strategic view lives in your flight. When someone asks "how's the project going?" - the flight status and its crate links give them the answer at whatever level of detail they need.