Engineering · Use case

“What's slowing the team down this sprint?”

After the retro, find out why. Spoke interviews every engineer on their own and follows up on the sticky notes that just said “reviews” or “CI,” so you plan the next sprint with the reason in hand.

The answer

Review wait time, not review quality, is the bottleneck.

An example of the line the Agent Results Brief leads with.
01 · The questions

The questions Spoke asks after the retro

Under every question is the follow-up Spoke asks when the first answer is vague. That second question is where the real answer usually is.

The sprint

When to ask: every time, first
  1. What slowed you down most this sprint?

    If the answer is vague, Spoke asks

    Think of the last time it happened. What were you working on?

  2. What did you work around instead of fixing?

    If the answer is vague, Spoke asks

    What made working around it feel faster than fixing it?

  3. What took longer than you expected this sprint?

    If the answer is vague, Spoke asks

    Where did the extra time go?

  4. What would have made this sprint feel easier?

    If the answer is vague, Spoke asks

    Which ticket made you wish for that most?

Handoffs and waiting

When to ask: they mention reviews, blockers or waiting on someone
  1. Where did you wait on someone this sprint?

    If the answer is vague, Spoke asks

    How long did it sit before anyone picked it up?

  2. Which handoff hurt most?

    If the answer is vague, Spoke asks

    What was missing when it reached you?

  3. What did you need to start a ticket that you didn't have?

    If the answer is vague, Spoke asks

    Who had it?

Meetings and interruptions

When to ask: they mention meetings, chat pings or on-call
  1. If one meeting disappeared, which one?

    If the answer is vague, Spoke asks

    What would you do with that time instead?

  2. What pulled you off planned work this sprint?

    If the answer is vague, Spoke asks

    How long did it take to get back into what you were doing?

  3. How much uninterrupted time did you get on a typical day?

    If the answer is vague, Spoke asks

    What broke it up most often?

Tooling and CI

When to ask: they mention builds, tests, deploys or local setup
  1. What in the build or deploy slowed you down this sprint?

    If the answer is vague, Spoke asks

    Which step were you waiting on the last time it was slow?

  2. Which tool do you work around most?

    If the answer is vague, Spoke asks

    What does the workaround cost you in a normal week?

  3. What part of testing a change feels harder than it should?

    If the answer is vague, Spoke asks

    What did you do the last time to get around it?

What went well

When to ask: last, so the plan keeps what works
  1. What went well this sprint that we should keep?

    If the answer is vague, Spoke asks

    Who or what made that work?

  2. Who helped you most this sprint?

    If the answer is vague, Spoke asks

    What did they do that made the difference?

  3. What did you ship this sprint that you're glad about?

    If the answer is vague, Spoke asks

    What made that one go more smoothly than the rest?

Send these questions Spoke asks each person on their own and follows up on every vague answer.
02 · The interview

How the interview goes.

Every person gets interviewed, not surveyed. Spoke asks, listens, and follows up on what that person actually said. Here's an example.

Spoke
5 min
Think back over the sprint. Where did you spend time waiting on someone else?
Reviews, mostly. My PR sat for two days and then got a one-line approve.
Two days and then a quick approve. How often does that happen?
Most weeks. Everyone's heads-down on their own tickets, so reviews are last.
If reviews were picked up within a few hours, what would you have shipped this sprint that you didn't?
03 · The answer

What the answer looks like.

Read the answer, not the transcripts: themes ranked by how many people raised them, the quotes behind each, and the places where two groups disagree.

Agent Results Brief Final
Summary

The team is not blocked on review quality; it is blocked on review wait time. Most people describe PRs idling for a day or more, then getting a quick approve, and several say they started batching changes to avoid the wait.

On why reviews wait, two groups disagree on the root cause.
Nobody owns reviews · 15
PRs are too big · 9
What to change before planning
1Name a reviewer before a PR opens; review is the first task of the day.
2Cap PRs at one ticket; split anything larger before review.
3Move the flaky suite to a nightly run and unblock merges.
What people said · Review wait time
“Two days idle, then a one-line approve.”
“I batch changes now so I only wait once.”
“Reviews are nobody's job, so they're last.”
Themes · 38 responses
Review wait time27
Interrupt-driven days16
Flaky CI reruns11
Unclear ticket scope5
Sentiment
34% positive41% mixed25% negative

An example Agent Results Brief. The counts, themes and quotes are illustrative, not from a real survey.

After the retro

A retro board, then an interview with every engineer

Keep the retro. Run it on a retro board, open with one of the icebreaker questions, and collect the sticky notes. Then send one link, and Spoke asks each engineer about the notes the board left vague.

A retro board
  • Everyone sees the same themes at once, which is good for talking them through together.
  • A sticky note says “reviews” or “CI.” It doesn't say which review, or how long it sat.
  • The loudest voices can shape the discussion.
  • Quieter people may vote on other people's notes rather than add their own.
An interview with every engineer
  • Each person answers alone, in the browser, for the time you set.
  • “Reviews are slow” gets a follow-up: which PR, how long, and what they did while they waited.
  • The people who stayed quiet in the retro get the same questions as everyone else.
  • You get the reasons ranked by how many people raised them, before planning.
Past the sticky note

What the sticky note meant

Retro notes are short on purpose. Here is what one follow-up turns them into. Examples, not real respondents.

Example · The day after the retro, anonymous
QuestionWhat in the build or deploy slowed you down this sprint?
First answerCI, same as always.
Spoke follows upWhich step were you waiting on the last time it was slow?
Real answerThe end-to-end suite. It fails about once a day on a test nobody owns, so I rerun it and go get coffee. Twice on Thursday.
What it uncovered

Not slow CI in general: one flaky suite with no owner.

Example · Two days after the retro
QuestionWhat pulled you off planned work this sprint?
First answerThe usual interruptions.
Spoke follows upHow long did it take to get back into what you were doing?
Real answerMost of a morning, twice. Support pinged me directly about the billing export because I built it last year. I'm still the only one who knows it.
What it uncovered

One engineer is the only path to an old system, and support routes around the on-call rota to reach them.

Example · The day after the retro, anonymous
QuestionWhat did you need to start a ticket that you didn't have?
First answerClearer tickets, I guess.
Spoke follows upWho had it?
Real answerDesign did. The mockup for the settings page was in a thread I wasn't in, so I built from the old one and redid half of it.
What it uncovered

The ticket wasn't vague; the design lived somewhere the engineer couldn't see.

04 · How to run it

Three steps, ten minutes.

  1. Write or pick the questionStart from “What's slowing the team down this sprint?” or say it your own way. Spoke drafts the goal, the audience and the follow-ups; you edit any of it.
  2. Send the linkShare one link however you reach people. They answer in the browser; you set the time: 5, 10 or 15 minutes (10 by default).
  3. Read the answerThemes ranked by how many people raised them, the quotes behind each, and what to do first. Every transcript is there too.
Send these questions

What do you want to learn, and who's answering?

What slowed the team down this sprint, and what should we change before planning.

Drafted the spec. Want me to ask about on-call separately, or let it come up?

Live survey spec
Goal
What to change before the next sprint, from the people doing the work.
Audience
Everyone on the sprint, anonymous
Topics
Waiting and handoffs
Meetings and interruptions
Who asks this

People who need the answer.

Engineering managers
Find out what the sprint felt like before you plan the next one.
Tech leads
Hear the handoff that hurt from every side of it, not the loudest one.
Scrum masters and coaches
Run the retro on the board, then interview the people who stayed quiet.
Platform and DX groups
Ask every engineer what they work around, and rank the answers.
Retro boards are free, no limits
FAQ

Questions about this one.

Is this a retrospective?

It follows one. Run the retro on a board as usual, then send one link: Spoke interviews every engineer, on their own, about what the board left vague.

What should I ask after a retro?

Start with what slowed people down most and what they worked around instead of fixing. Then add the group that matches the sticky notes: handoffs, meetings, or tooling and CI.

Can the team answer anonymously?

Yes, on paid plans. Anonymous responses are a setting you choose per survey; if it isn't turned on, don't promise anonymity.

How long does an interview take?

You set the time: 5, 10 or 15 minutes, 10 by default. Spoke follows up on what that person actually said, so nobody answers questions that don't apply to them.

What do I get at the end?

The Agent Results Brief: a summary, themes ranked by how many people raised them, the places where two groups disagree, and the quotes behind each. Every transcript is there too.

Related

Ask your first question.

Free to start. No card. Your first ten agent surveys are on us.