An Agile jargon field guide for the executive who funds your team

After a quarterly review last spring, the VP who signed our funding walked me to the elevator and lowered his voice like he was about to confess something.

"Can I ask you something embarrassing? I've been nodding at the word velocity for over a year. I don't actually know if ours is good."

This is a man who approved seven figures a year for delivery work. He could read a P&L upside down. And for a year he'd been pricing risk on words he couldn't translate, because nobody thought to hand him the phrasebook.

I've thought about that elevator ride a lot, because he isn't the exception. He's the rule. Most executives I've briefed do the same quiet math: the words go by, the confidence in the room seems fine, so they nod and wait for the numbers slide. Which means the people funding the work are often the only people in the room translating none of it.

So this one's for you, the person whose name is on the budget. It isn't a glossary. It's a field guide: what the words actually mean in money and risk, which ones are healthy signs, which ones should make you sit up, and what to ask instead of the question everyone asks.

Every one of these words is a claim on your money or your risk

First, a reassurance. Agile jargon wasn't invented to keep you out. Inside a team it's genuinely useful shorthand: one word instead of a paragraph, said forty times a day. The trouble starts when the shorthand leaks into a funding meeting untranslated and everyone is too polite to stop the room.

You don't need to learn the framework. You need one listening skill. Every term below is secretly a claim about money, a claim about risk, or both. Hear it that way and most of the fog lifts on its own.

Sprint: a fixed-size purchase

A sprint is a fixed-size purchase. Two weeks of the team's full cost: salaries, tools, overhead, all of it. When a team says "we'll have it in two sprints," they're telling you the price. They've just left the currency off.

Healthy sign: sprints that end with something you can see working, even if it's small. Warning sign: a run of sprints that end with "good progress" and nothing you could click. You wouldn't accept "progress" from the contractor renovating your kitchen. Worth asking: "what will I be able to see at the end of it?"

Velocity: the team's pacing number, not a report card

Velocity is the word my VP confessed about, so let's do it properly. It's the team's own pacing measure: how much work, in their own sizing units, they finish per sprint. Its whole job is to help that one team forecast itself.

Here's what it isn't: a productivity score. The units aren't standard, so comparing velocity across teams is comparing my recipe's "pinch" to yours. And when it drops, the drop is a symptom with a dozen possible causes. Vacations. A genuinely hard problem. Hidden rework. A hiring gap.

So "why is velocity down" is the wrong question, because teams answer it by making the number go back up, which is easy and tells you nothing. The real question is "what changed in the work or the team?" That one gets you an answer you can act on.

Backlog: the list of things you haven't bought yet

When you hear "it's in the backlog," it sounds like your request is in a queue, inching forward. It usually isn't. A backlog is everything anyone has ever asked for, written down so it isn't forgotten. Most of it will never be built, and that's by design.

The honest translation: recorded, not scheduled. Nothing in a backlog has money behind it until it's understood, prioritized, and pulled into a sprint.

Healthy sign: "it's in the backlog, and here's when it gets decided." Warning sign: "it's in the backlog" used as a polite burial. Worth asking: "who decides when it comes out, and when?"

Tech debt: interest you're already paying

Tech debt is the most honest metaphor in software, and executives routinely hear it as engineers complaining. It isn't. It means that at some point the team chose speed over durability, sensibly or not, and now every new feature costs a little more because it's built on that shortcut. You're already paying the interest. It shows up as features that take longer each quarter and releases that break in surprising places.

Healthy sign: debt that's named, sized, and paid down alongside feature work. Warning sign: debt as a permanent, unquantified apology. Worth asking: "what's the interest costing us, and what's the payment plan?"

Spike: buying information before you buy the feature

A spike is the team spending a small slice of a sprint buying information instead of features. Can this vendor's API handle our volume? Is the migration as scary as it looks? To a funder it can sound like a stall. It's the opposite. It's the cheapest risk retirement you'll ever fund: a few days of one person's time to avoid betting a quarter of the roadmap on a guess.

This one is almost always a healthy sign. The question that makes teams trust you: "what are we hoping to learn, and what will we do differently once we know?"

Definition of done: what finished actually includes

Every good team keeps a written standard for what "done" includes: tested, reviewed, deployed, monitored. That standard exists so "done" can be a full sentence on its own.

So listen for the second clause. "Done, but not tested." "Done, waiting on deployment." Every "done, but" means your money has bought inventory, not outcome: work that's finished on a board and earning nothing. One or two are normal life. A pattern is a warning. Worth asking: "when you say done, can a customer use it?"

Blocked: the word that deserves your full attention

Of all seven, this is the word that most deserves an executive's attention, and it gets the least. Blocked means the team is stopped and the run rate isn't. You're paying full price for a team that can't ship, usually while they wait on something outside their control. An approval. A vendor. Another department's queue.

Here's what makes it interesting for you specifically: the blocker often lives at your altitude. A ten-minute phone call from you can be worth more to that team than anything else you do for them all month. Worth asking, every single time: "who's holding it, and is that someone I can call?"

The pocket card for your next status meeting

Nobody remembers seven entries mid-meeting, so here's the version that fits on a card. Four phrases you'll hear this quarter, priced.

Telling a weather report from a decision

One more listening skill and you're dangerous. Everything said in a status meeting sits somewhere on two lines: how specific it is, and whether it's asking you for anything.

Specific words attached to a decision are the real thing. Lean in, because the team is handing you a choice only you can make. Specific words attached to nothing are a weather report: nod and note it. The vague words are the ones you have to work. Vague and asking nothing is smoke, so ask one question and see what's underneath. Vague and demanding a decision is the one combination that should genuinely slow you down. "We just need two more sprints" with no story under it isn't a request. It's a hope wearing a suit.

Three swaps that change what your teams bring you

If you take one practical thing from this guide, take these.

Instead of "why is velocity down," ask "what changed in the work or the team?" The first question produces a defended number. The second produces information.

Instead of "when will it all be done," ask "what will be usable by the date, and what's most at risk?" "All done" is a fantasy in any honest software effort. Usable-by-when is an answer a team can stand behind.

Instead of "can you go faster," ask "what would you have me remove?" Faster is almost never about effort. It's about scope, interruptions, and blockers, and two of those three are usually yours to change.

Ask these for a month and watch what happens. Teams stop performing for you and start briefing you. The fog you thought was Agile turns out to be translation, and translation is cheap.

And if you're the practitioner reading this over your sponsor's shoulder: yes, send it to them. Then steal the habit yourself. The teams that get funded again aren't the ones with the best velocity. They're the ones whose funders always understood what they were buying.

What the VP does now

My VP never did learn Scrum, and he didn't need to. He picked one translated question per meeting and asked it plainly, sometimes reading it off a note. Within a quarter his teams briefed him differently: less vocabulary, more money and risk, because that's what he kept rewarding.

That's the quiet lesson of the whole field guide. Teams speak the language their funders reward. Ask about jargon and you'll get jargon back. Ask about money and risk, kindly and consistently, and the jargon translates itself.