Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Uses Leading Indicators to Predict Sprint Success
Transcript
- Lucas: So there's this CTO at a mid-size SaaS company — about eighty engineers — who told me he stopped caring about velocity about eighteen months ago. Completely dropped it from his weekly dashboard. Luna: Velocity — that's like, story points per sprint, right? The classic? Lucas: Right. And he said velocity is a rearview mirror. It tells you what already happened. By the time you see velocity dip, that sprint is already over. You can't fix it. So he shifted to what he calls leading indicators — metrics that predict the finish before you cross the line. Luna: Okay, I love that framing. What did he actually put on the dashboard? Lucas: Three things. First: cycle time for items currently in progress — not historical average, but right now. If a ticket has been 'in dev' for five days and the team's median cycle time is three, that's a red flag before the sprint ends. Luna: So you catch the slow ticket while it's still moving, not after it misses the deadline. Lucas: Exactly. Second: work-in-progress count per developer. He caps it at two. If someone has four open tasks, the system flags it. That's a leading indicator of bottleneck — because multitasking kills throughput. And third: scope-change rate — how many new requirements get added after sprint planning, expressed as a percentage of the original commitment. Luna: The scope-change one is interesting. Most teams track scope creep after the fact — like, 'oh we added 40% more work'. But he wants to see it in real time. Lucas: Right. He told me the dashboard lives on a TV in the engineering area, updated hourly. Any team member can look up and see: are we green, yellow, or red on each indicator. And the rule is, if two of three are yellow or red, the team does a fifteen-minute regroup — no blame, just re-prioritise. Luna: That's such a low-friction response. It's not a full retrospective, it's a quick check. Lucas: And it works because the indicators are objective. You can't argue with a cycle-time clock. The CTO said the first quarter after they started, overcommitment — meaning sprint goals that didn't ship — dropped by twenty-two percent. Not because they planned fewer points, but because they caught the issues mid-sprint and adjusted. Luna: Twenty-two percent in one quarter — that's a real signal. Did any one indicator turn out to be more predictive than the others? Lucas: He said the most surprising was work-in-progress count. Turns out, when a developer has more than two active tasks, their cycle time on each task doubles on average. So WIP is basically a proxy for systemic overload. And it's visible before any deadline slips. Luna: That's fascinating because it's so simple. You don't need a data engineer to measure that. Lucas: And that's the point. He chose indicators that any team could pull from Jira or GitHub or even a whiteboard. No special tooling. The hardest part was getting the team to trust the data instead of their gut. Luna: How did he get buy-in? Engineers can be skeptical of dashboards. Lucas: He ran a two-week experiment on one team. They put the three indicators on a shared spreadsheet — no automation — and asked the team to check them every morning standup. After two weeks, that team had finished their sprint with zero overcommitment for the first time in six months. Other teams saw the result and wanted in. Luna: That's a great example of leading with evidence. 'Trust me, look at this spreadsheet' — and it worked. Lucas: Yeah. And honestly, conversations like this are exactly why we keep this show going. If today's tech conversation gave you something usable, a couple of dollars a month is genuinely what keeps these going — buy me a coffee dot com slash fexingo, if you've gotten something out of them. Luna: Absolutely. It helps us stay ad-free and focused on real stories like this one. So back to the dashboard — after the experiment, how did he scale it? Lucas: He automated the data pull into a simple Grafana dashboard. Every morning, the lead engineer gets a Slack notification with the current state of each indicator for their team. No extra meetings. Just a data point to start the day. Luna: So the leading indicators also become a communication tool — the Slack message replaces the 'how are we doing' question. Lucas: Exactly. And one more thing he added later: a fourth indicator — the ratio of accepted to rejected pull requests over the last three days. If that ratio drops below two-to-one, it suggests the team is reviewing too hastily or the code quality is dipping. That one flagged a systemic review bottleneck three sprints before it showed up in delivery data. Luna: Three sprints early — that's the whole point of leading indicators. What did they do about the review bottleneck? Lucas: They found that two senior engineers were approving PRs without actually reading the diffs — just clicking through to unblock people. So the team instituted a rule: no zero-comment approvals. Every PR needs at least one substantive comment. That alone improved the acceptance ratio by thirty percent in a month. Luna: So the indicator didn't just flag a problem — it pointed to a specific behavior to fix. Lucas: Right. And that's what separates leading indicators from vanity metrics. Velocity tells you 'we shipped X points'. A leading indicator tells you 'we have a review quality issue that will slow us down next sprint if we don't change something now'. Luna: I want to ask about the scope-change rate. How did they define that? Is it just tickets added after the sprint starts? Lucas: Pretty much. They divide the number of new story points added after sprint planning by the original total. Anything above fifteen percent triggers a yellow flag. Above thirty percent is red. And if it's red, the team has to decide: either drop something of equal size, or extend the sprint — but they have to make that call within 24 hours. Luna: That forces the trade-off conversation immediately, rather than just silently absorbing the extra work. Lucas: Exactly. And the CTO said that rule alone cut unplanned work by forty percent in one quarter. Because product managers knew that if they added a new feature mid-sprint, something else had to come out. So they became more disciplined about what was truly urgent. Luna: I love that the indicators also change behavior upstream. It's not just monitoring, it's shaping how people plan. Lucas: That's the ideal. And I think the reason this works is that the indicators are few, visible, and tied to a specific action. Not a dashboard with thirty charts that nobody looks at. Three numbers, one Slack notification, and a fifteen-minute regroup when needed. Luna: It sounds almost too simple. Did he encounter any resistance from teams who felt micromanaged? Lucas: Some, initially. Especially around WIP count. Developers said 'sometimes I need to context-switch' or 'I have a high-priority bug while I'm mid-task'. But the CTO made it clear: the indicator doesn't punish you. It's a signal to the team that you might need help. If your WIP is high, the team should swarm on your open items to unblock you, not judge you. Luna: So it flips from individual accountability to team responsiveness. That's a cultural shift. Lucas: It is. And he said that shift was key. Once the team saw that a red WIP indicator meant someone else would offer to pair or take a task off their plate, the resistance melted. It became a safety net, not a stopwatch. Luna: Any final piece of advice from him for a team that wants to start tomorrow? Lucas: Pick one. Don't try all three. He said start with cycle time for items in progress — it's the easiest to measure and the most revealing. Put it on a whiteboard for one sprint. See what happens. The data alone often leads to the next question, and you build from there. Luna: One indicator, one sprint, one whiteboard. That's about as low-barrier as it gets. Lucas: And honestly, most teams already have the data — they just aren't looking at it the right way. Cycle time is right there in your ticket system. You just need to look at the ones that are open, not the ones already closed. Luna: That's a great reframe. Thanks for unpacking this — I'm actually going to try the cycle-time thing with my own team. Lucas: Let me know how it goes. Maybe we'll do a follow-up in a few months.