Planning a Flight

A well-planned flight is half the battle. But "well-planned" does not mean "exhaustively specified." It means the team knows where they're going, who's flying, and roughly what cargo they're carrying. Everything else gets figured out in the air.

Scoping the Flight

The single most important question when scoping a flight is: what will be different when this lands? Not "what tasks will we complete" or "how many story points will we burn through." What outcome will the team have delivered?

A flight is a coherent initiative. It has a clear beginning and a clear end. "Improve the checkout flow" is a flight. "Work on miscellaneous frontend stuff" is not. If you can't describe the flight's purpose in a single sentence, you probably need to split it into multiple flights.

Keep the scope tight. The ideal flight duration is 1-3 weeks. Long enough to deliver something meaningful, short enough to maintain focus and urgency. If your flight scope feels like it needs six weeks, you're almost certainly bundling multiple initiatives together. Break them apart.

Resist the urge to scope everything upfront. You're planning a flight, not writing a specification. The team will discover details during the flight that you can't predict now. That's not a failure of planning - that's how software works. Define the destination clearly, and trust the crew to navigate the route.

Setting Dates

Every flight has two dates: a takeoff date and a landing date. The default flight length is 14 days, but your team can adjust this to whatever cadence works best. Some teams prefer one-week sprints. Others do three weeks. The tool adapts to you, not the other way around.

Dates serve as a forcing function. They create healthy pressure to ship. Flights that run too long are a signal that something has gone off track. This isn't about cracking the whip. It's about making delays visible so the team can react before a small slip becomes a big problem.

Short flights with clear deadlines consistently outperform long, open-ended ones. When a flight has a two-week window, the team naturally prioritizes what matters and defers what doesn't. When a flight has no clear end date, work expands to fill whatever time is available - and then some.

Be realistic when setting the landing date. Optimism is great for morale but terrible for planning. If your team has never shipped a checkout redesign in under three weeks, don't plan a two-week flight for it. Use your history as a guide, add a small buffer for the unexpected, and commit to the date.

Assembling the Crew

Start by picking a captain. The captain is the single person accountable for getting this flight to its destination. They don't have to do all the work - but they own the outcome. If the flight lands late or doesn't land at all, the captain is the one who explains why.

Then add crew members. The best crews are cross-functional - a mix of skills that covers everything the flight needs. If the flight involves frontend work, backend changes, and design updates, make sure the crew includes people who can handle each of those areas. Don't assume someone else will "pick it up."

Not everyone needs to be on every flight. In fact, smaller crews tend to move faster. Two to four people is the sweet spot for most flights. If you need more than six people, your flight scope is probably too broad. Split it.

Consider who's available. Check your team's current flight assignments - are the people you want already on other active flights? Overloading individuals across multiple flights is one of the most common mistakes teams make. A focused crew member on one flight delivers more than a distracted one on three.

Loading Initial Crates

Crates are the individual pieces of work that make up a flight. Think of them as the cargo you're loading before takeoff. Each crate should represent a discrete, deliverable chunk of work - something that can be linked to an issue in your tracker and marked as done independently.

Break the flight scope down into crates, but don't over-plan. You want enough crates to give the crew a clear starting point, not a comprehensive task list that accounts for every possible edge case. A good rule of thumb: if your initial crate list covers about 60-70% of what you think the flight needs, you're in good shape.

Some crates will emerge during the flight. That's expected and healthy. The crew will discover edge cases, uncover hidden dependencies, and identify improvements that nobody could have predicted during planning. The captain adds these as new crates when they come up.

Link each crate to your issue tracker - GitHub Issues, Linear, Jira, whatever your team uses. The crate in Flights is the high-level tracking unit. The linked issue is where the detailed technical discussion happens. This separation keeps your flight board clean while preserving all the context developers need.

Pre-Takeoff Checklist

Before you move a flight from takeoff to active, run through this mental checklist. It takes thirty seconds and saves hours of confusion later.

• Is the scope clear? Can every crew member describe what "landed" looks like in one sentence?
• Is a captain assigned? One person, clearly accountable.
• Is the crew assembled? Does the team have the skills to deliver everything the flight needs?
• Are initial crates loaded? Does the crew know where to start on day one?
• Is the landing date realistic? Based on actual team capacity, not wishful thinking?

If you can answer yes to all five, take off. If not, spend a few minutes fixing whatever is missing. The goal isn't perfection - it's clarity. A flight with a clear scope, a committed captain, and a realistic date will almost always outperform one that launches with ambiguity, even if the ambiguous flight had more "planning" time.

Don't let planning become a bottleneck. The point of a pre-takeoff check is to catch obvious gaps, not to achieve certainty. In the time you spend trying to plan away all risk, you could have taken off, discovered the real problems, and started solving them.