Measuring a team at agent pace: waiting, rework, pick-up time
By Soumen Sarkar · October 2026
Playbook. Measure what slows a team of people and agents down: waiting time, rework, pick-up time and late surprises. Each one points at a fix.
How do you measure a team at agent pace?
Measure what slows the work down: how long work waits on people, how much of it is redone, how quickly unfinished work is picked up, and how late surprises arrive. Those four tell you where the team's way of working needs fixing. Output counts, such as changes merged or lines written, rise on their own when agents do the typing, and they tell you very little.
This playbook sets up those four measures with whatever tools you have, and a weekly habit that turns each one into a fix.
Who is this for?
Leads who want to know whether their team is working well when every person runs several agents and dozens of changes land each day. Also developers who want to see where their own sessions lose time.
What do you get?
- Four measures that point at specific problems, each with a fix.
- A weekly look that takes minutes, built from what the team already writes down.
- A way to talk about the team's flow without ranking people.
Why don't output measures work any more?
When an agent writes most of the code, the number of changes is mostly a function of how many agents are running. It goes up when you add sessions and tells you nothing about whether the work fits together. A team can ship far more changes in a week while redoing much of what it shipped the week before.
The useful questions are about flow. Is anyone waiting? Is anything being done twice? Does unfinished work move on, or sit? Do mistakes surface early, while they're small? That's what fix forward asks of a team: catch mistakes early and correct the course in the flow of the work. The measures below show whether that's happening.
What are the four measures?
- [Waiting time](/glossary/waiting-time): how long work waits on a person. Mostly, the time from an assumption or question being stated to someone confirming or correcting it.
- [Rework](/glossary/rework): work done again because something wasn't known in time: a wrong assumption caught late, a decision nobody found, two changes going opposite ways.
- [Pick-up time](/glossary/pick-up-time): how long a handoff waits before someone continues the work.
- Late surprises: problems found after the work built on them has moved on. A wrong assumption corrected after merge, or a clash between decisions found in review rather than when the second one was written.
Each of these points at something to fix. That's the test for any measure you add: if it moving wouldn't change what you do, don't track it.
Step 1: Make the events visible
You can't measure what isn't written down. Before counting anything, make sure the team records the events the measures are built from:
- Assumptions are written as one line, with the time, wherever the team keeps them. The assumption line template works in a pull request description.
- Answers are written next to them: confirmed or corrected, by whom, when.
- Handoffs are written when work stops, with the time, and marked when someone continues it.
- Decisions are recorded with reasons, and a replaced one is marked superseded.
Most of this is already part of working the VibeFlock way. The measures come from it for free.
Step 2: Measure waiting time
For a week, look at each stated assumption and note how long it waited for a person. Split them two ways:
- Answered from the record versus answered by a person. A question the record already answered should never have waited at all.
- High stakes versus normal. High-stakes assumptions (data, money, access, public interfaces, deleting things) should be answered first.
Example: an agent in Billing · lib/billing assumes "refunds return to the original card". If that's answered in twenty minutes, fine. If it waits until the next day while the agent builds three more changes on it, that's waiting time the team pays for later.
Step 3: Measure rework
Ask every change that redoes earlier work to say so in its reasons, with why: "Redoes the refund flow from Tuesday, because the assumption about original cards was corrected." Then, once a week, read those lines.
The count matters less than the causes. Group them:
- Wrong assumption caught late.
- A decision existed but nobody found it.
- Two pieces of work in progress went opposite ways.
- The plan changed for a good reason.
The last one is healthy. The first three each point at a fix.
Step 4: Measure pick-up time
For each handoff, note when it was written and when someone continued the work. A handoff picked up within the day keeps the work moving. One that sits for three days is unfinished work that has quietly stopped, and anything built on it is at risk.
Step 5: Count late surprises
Note each time a correction or a clash arrived after the work built on it had moved on: merged, released, or built on by someone else. These are the expensive ones. A team working well finds most surprises early, while they're one line to fix.
Step 6: Look once a week, and pick one fix
Read the four measures together, briefly. Look at direction, not targets. Then pick one fix for the week, matched to what you see:
- Many questions answered by people that were already in the record: the record isn't findable. See making a team's knowledge findable by every agent.
- Long waits on high-stakes assumptions: the right person isn't seeing them first. Give each area someone who answers for it.
- Rework from decisions nobody found: decisions aren't reaching the next agent. See recording decisions as agents work.
- Rework from opposite work in progress: plans aren't visible. See working in parallel on dependent changes.
- Slow pick-up: handoffs are too thin to continue from, or the team has too much in flight.
- Late surprises: assumptions are stated but not answered before merge.
One fix a week, chosen from the evidence, is how the measures earn their place.
Here's how a weekly look might go, as a hypothetical. A four-person team sees that several assumptions in Search · lib/search waited most of a day, and two of them were already answered by a decision from the week before. That's waiting time caused by a record nobody found. The fix: put the decision at the top of the Search area summary and tell agents to read it before changing anything there. The next week, the same kind of question is answered from the record in minutes.
What instructions should agents get?
Agents can make the measures almost free by writing a few things as they go:
- When you state an assumption, write it as one line with the likely answers and
the stakes, where the team keeps assumptions.
- When your change redoes earlier work, say so in its reasons: what it redoes
and why.
- When you stop unfinished, leave a handoff. When you continue someone else's
handoff, say so at the start of your plan.
- When you find that a decision you needed already existed, say where you found it.
What should you watch for?
- Measuring people. These are measures of the team's flow. The moment they become a ranking, people stop stating assumptions and stop admitting rework, and the measures go dark.
- Invented targets. "Every assumption answered in an hour" sounds good and invites gaming. Watch the direction and the causes.
- Measures that don't lead anywhere. If a number moves and nobody changes anything, drop it.
- Hiding healthy rework. Changing course because you learned something is the point of fixing forward. Count it, but don't treat it as failure.
- Skipping the recording. If assumptions and handoffs aren't written down, the measures will look good because nothing is being counted.
How do you know it's working?
- The weekly look ends with one concrete fix, and the following weeks show whether it helped.
- More questions are answered from the record and fewer wait on people.
- Rework, when it happens, has causes the team recognises and is fixing.
- Handoffs are picked up within the day.
- Surprises arrive earlier: in the session, not in review, and not after release.
What does Campfyrr automate?
Campfyrr records the events these measures are built from as the work happens, and shows them on each project's Activity page.
- A weekly card at the top, "What Campfyrr caught for your team this week": questions answered from the record, assumptions stated and confirmed, handoffs picked up and how fast, clashes caught, and wrong assumptions caught.
- The events themselves: assumptions stated with
state_assumption and settled from the record or by a person; high-stakes ones marked and shown first; handoffs written from Claude Code sessions when they stop, compact or end, and shown in the feed as work paused partway; decisions checked for clashes as they're recorded. - Filters by person, area, and since a date or your last visit, so you can look at one part of the code or one week.
Campfyrr doesn't read your code or diffs, or run CI, so it doesn't count reverts or test failures. If you want those alongside, take them from git and your CI, and read them with the causes Campfyrr shows.
Measuring this way keeps the team honest in the way fix forward asks: mistakes are expected, caught early, and each week's numbers lead to one small correction in how the team works.
The principle behind this: Fix forward: We don't guard the gate. We correct the course.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).