Every two weeks, our engineering team would present sprint metrics to the leadership team. Velocity charts, burndown graphs, story points completed versus planned. Every two weeks, the same polite confusion.
The translation problem
"Sprint velocity dropped 15% this cycle." That was the sentence that broke us. Our CTO said it in a Monday standup to the CEO. The CEO nodded politely. The head of product pulled up a Jira dashboard. The head of sales checked his phone.
Nobody in that room - outside of engineering - had any idea what sprint velocity meant. Not because they weren't smart. Because the language was invented by engineers, for engineers, and it carries zero intuition for anyone who hasn't been trained in it.
What does a "velocity of 42" mean? Is that good? Bad? Is 42 better than 38? It depends on the team, the sprint, the complexity, the alignment of Jupiter with Mars. It's a number that only has meaning within its own self-referential system. It's not a measure of anything real. It's a measure of how many imaginary points your team agreed to assign to tasks they haven't done yet.
Language shapes understanding
After switching to the Flights methodology, something unexpected happened. Our CEO started asking better questions. Not because we trained him on our process, but because the metaphor did the training for us.
"This flight is hitting headwinds but still lands Friday." Everyone in the room immediately understood three things: there's a problem, it's being handled, and the deadline holds. No follow-up questions. No confused glances at a burndown chart.
"We had to make an emergency landing on the payments integration." Instant understanding: something critical broke, the team stopped what they were doing to deal with it, and there will be a delay on other work. Try expressing that with sprint terminology. "We had to break the sprint to address a P0 that wasn't in the backlog, which affected our velocity and will require re-estimation of carry-over stories in the next sprint planning session." Same information, three times the words, zero intuition.
The metaphor isn't decoration
When we first introduced Flights internally, a few engineers rolled their eyes at the aviation theme. "It's just a metaphor," they said. "Does it really make a difference?"
It does, and here's why: metaphors that map to universal experience lower the cognitive load of communication across teams. Everyone has been on a flight. Everyone understands that flights have departures and arrivals, that they can be delayed, that turbulence happens, and that someone is in the cockpit making decisions. Nobody needs training to understand these concepts.
Compare that to Scrum's vocabulary. Sprint. Backlog. Grooming. Refinement. Story points. Velocity. Epic. Saga. Ceremony. Each of these is a term of art that must be learned. And the worst part is that half of them have everyday meanings that are actively misleading. A "sprint" implies speed. "Grooming" implies care. "Velocity" implies measurement. None of these words mean what they suggest when used in a Scrum context.
Status updates that cross the aisle
Here's what our status updates looked like before and after:
Before: "Sprint 47 is at 65% completion with 23 of 35 story points delivered. Two stories are blocked pending API changes from the platform team. We're carrying over 12 points to Sprint 48, which will affect our projected velocity."
After: "The checkout rewrite flight is on schedule and lands Thursday. Two crates are waiting on the platform team - we've flagged headwinds but the captain expects to land on time. The authentication flight landed yesterday, clean landing, all crates delivered."
Both convey the same information. The second one can be understood by anyone in the company - the CEO, the head of sales, the new intern, the board member who asks "so what's engineering working on?" once a quarter.
Communication is a feature, not a side effect
Most engineering methodologies treat communication as a bolt-on. You do the work inside your framework, then translate it for outsiders. Flights treats communication as a first-class feature of the methodology itself.
When you say "we have three flights in the air and two on the runway," everyone can immediately picture the workload. When you say "that flight's captain called an emergency landing," everyone knows it's serious. The vocabulary does the communication work for you.
This isn't about dumbing things down. It's about using language that carries shared intuition. Your stakeholders aren't failing to understand velocity because they're not paying attention. They're failing because the language was never designed for them. That's not their fault. It's ours for expecting them to learn our jargon instead of meeting them where they are.
If you want to see how we structure status communication in practice, the core principles section of the handbook covers it in detail.