Delivery: what interviewers score and how to build the story

Delivery is shipping something real under constraints that were not of your choosing — deadlines, dependencies, incomplete information, and requirements that changed while you worked.

Delivery stories are the most common kind in candidate story banks, and the most commonly weak, because the tension gets edited out in the retelling. This lesson defines what is actually scored, lists the indicators and the phrasings that probe them, and gives you three tests and a card format for building a story that keeps its tension.

The definition

The phrase to hold onto is what not to do. A delivery story where everything in the original plan shipped on the original date has no decisions in it, and therefore nothing to score. This is counter-intuitive and it is the single most useful idea in the section.

What it is not

It is not working hard. Hours are an input. A story whose central fact is that you worked six weekends is a story about an estimate that was wrong and a plan that was not changed.

It is not initiative (Section 6). Initiative is choosing what to work on. Delivery is finishing something under conditions that made finishing hard. The same project can supply both stories, told with different emphasis.

It is not project management. Interviewers are not scoring whether you ran a good stand-up. They are scoring whether you can see a plan failing early and change it.

The constraint has to be named

Interviewers can tell the difference between "it was a tight deadline" and a constraint with a shape. A named constraint has a source, a date, and a consequence for missing it:

Vague: "We were under a lot of time pressure."

Named: "Our payment provider was decommissioning their v1 API — their application programming interface, the endpoint our checkout called — on 30 September. There was no extension — after that date, checkout returns errors. We found out fourteen weeks before, and the work as scoped was about twenty-two weeks."

The second version has done three things in twenty seconds: established that the deadline was external and immovable, given a number that makes the difficulty measurable, and set up every decision that follows.

Signals scored

With the constraint named, the interviewer is listening for four positive indicators, four negatives, and one that separates senior from mid.

The positive indicators

1. Prioritisation with a stated basis. Not that you prioritised, but how you decided:

"I ranked the six workstreams by whether checkout would return an error without them. Three were in that set, three weren't. That's the entire cut list — I didn't rank by effort or by who asked loudest."

The interviewer writes: had an explicit prioritisation criterion, applied consistently.

2. Trade-offs made explicitly and communicated. A cut nobody was told about is a bug report waiting to happen:

"I wrote a one-page note listing what was deferred, who it affected, and when we'd come back to it, and I got the two affected product managers to acknowledge it in writing before we started."

3. Dependencies managed rather than waited on. The strongest form is early detection:

"Their integration was on their roadmap for August. In week two I asked for their actual sprint plan rather than the roadmap date, and it showed August was optimistic. So I built a shim that let us cut over without them and treated their work as a follow-up."

4. Honest status while the outcome is uncertain. Interviewers probe this specifically:

"In week six my estimate went from 'tight' to 'we will miss this'. I said so that week rather than at the end, and I brought two options with it rather than only the problem."

The negative indicators

The one that decides it

When you told people you were going to miss. This is the highest-signal question in the competency and it is asked in almost every delivery interview in some form.

The scoring is roughly:

Notice that the outcome does not appear in that table. A project that slipped two weeks with early honest communication scores above a project that shipped on time after a silent month of overtime.

Questions asked

Eight phrasings open onto that one indicator list.

1. "Tell me about a time you had to hit a hard deadline."
2. "Tell me about a project that slipped. What happened?"
3. "How do you handle competing priorities?"
4. "Tell me about a time you had to deliver with incomplete requirements."
5. "Tell me about a project that didn't go as planned."
6. "Tell me about a time you had to say no to scope."
7. "Tell me about a dependency that put your project at risk."
8. "Walk me through the most complex project you've delivered end to end."

What each is really probing

Question 3 is not a story question, and that is a trap

"How do you handle competing priorities?" invites a method answer. Method answers score nothing:

"I usually look at impact versus effort, talk to stakeholders, and make sure the highest value work gets done first."

Generic, unfalsifiable, and true of everyone. Convert it to a story immediately:

"The way I'd answer that is with the last time it actually happened, if that's alright. In March I had the payments migration and an escalated customer bug at the same time, and I had to decide in an afternoon —"

Interviewers rarely object. Almost every "how do you" question in a behavioral round wants a "tell me about a time" answer, and converting it yourself is read as competence.

Question 2 requires a real slip

"Tell me about a project that slipped" is answered badly by candidates who reach for one where the slip was caused by something outside them. Choose one where your estimate or your plan was wrong. The failure question covers the same selection problem for the failure question, and the criteria are identical.

Building the story

Everything above tells you what a good delivery story contains. Three tests tell you whether your raw material has it.

Test 1 — the constraint was real and external

A constraint you set yourself is not a constraint. "We wanted to ship by the end of the quarter" is an ambition; missing it costs nothing you can name.

Real constraints have a source outside the team:

If your story has none of these, it may still be good work and it is not a delivery story.

Test 2 — you can name what you cut and why

This is the test most stories fail. Ask yourself: what did not ship, who decided, and on what basis?

If the honest answer is "we shipped everything", you have one of three situations:

• The project was over-estimated, and the story is about estimation, not delivery.
• Someone else made the cuts, and the story belongs to them.
• Things were cut and you have forgotten, which is common — go and look at the original scope document.

That third case is worth ten minutes of digging. Original planning docs almost always contain items that quietly vanished, and recovering them turns a flat story into a scored one.

Test 3 — you can say when you knew

Have the week number and the trigger. "About six weeks in, when the shim took four days instead of one, I knew the twenty-two-week estimate was real and the fourteen weeks weren't going to absorb it."

The story card

STORY — <name>Constraint   source / date / consequence of missingOriginal scope   the six thingsCut list     what was dropped, by whom, on what criterionDetection    week N, what changed my estimateCommunication  who I told, when, what options I broughtResult       what shipped, when, measured howWhat broke   the thing that went wrong anywayReflection   the decision I'd take earlier

Where to look for material

• Any project with an external date: a regulatory change, a partner deadline, a peak season
• Any project where someone left mid-way
• Any launch where the scope document and the shipped feature list differ
• Any time you were the one who said "this date is not going to happen"
• Any migration with a decommission date attached

The last category is the richest and most under-used. Migrations have hard dates, unavoidable dependencies, no user-visible glory, and forced trade-offs — which is a delivery interview's entire ingredient list.