Alright. Yep. I'm going there. Metrics, metrics, metrics, metrics. I know we're probably all tired of hearing that, but I find in our technology world we often don't know if we've solved our customer's problem until we've solved the customer's problem.
I talked about that with computational irreducibility—trying to predict when we're going to be done with our work amidst the unpredictable nature of our work. That's a tough thing to do. Customers aren't always sure what they want. Developers certainly aren't sure how to build everything. There is no playbook on how to solve for every problem. And how often does the tech solution change? All the time.
So yeah, we have metrics we capture to help us with these problems. Ever heard of velocity? Too often we use that to gauge delivery dates, but we miss the date. Well, what if velocity didn't miss your date? Velocity helped you miss it with confidence.
Hi, I'm Lance Dacy, otherwise known as Big Agile, and this week I'm very excited because we're talking about metrics—one of my favorite subjects. We're going to kick off with a conversation that I think a lot of leaders need, even though it probably makes us a bit uncomfortable at first. I'm going to talk about predictability without fantasy: flow over velocity.
Why Credibility Beats Confidence
My focus in helping teams in 2026 is going to center on how credibility can beat confidence. We've done the confidence thing for a long time, and heroic promises—they feel good in the moment, but they quietly erode trust over time. Teams are not better off for it, I can guarantee it.
So today I want to set the stage for the week ahead. We're going to talk about why velocity keeps letting leaders down, why flow metrics tell a better story, and how teams can rebuild trust after continued missed commitments. And let's do that without excuses, without spinning the data—let's be honest.
Why Predictability Is Broken
In most organizations—and I like to name the problem with grace, patience, and mercy—if this is you, don't hide from it. You're normal. Most organizations are under real pressure. Budgets are tighter than probably ever before. Timelines are public, they have to be. Leaders are expected to just know when things are going to be done and magically make it happen.
So naturally in Agile, our teams reach for the data: velocity. We even teach teams as agile coaches to use that. It's not a bad metric. Velocity feels scientific—it has numbers, it has charts. It looks precise, but you can be precisely wrong.
The hard truth is that velocity is internally negotiated and easy to game, and that's often done unintentionally as well. Teams can change story point sizing. You see work spill across sprints and scope quietly gets redefined without a lot of publicity. Suddenly we're out there forecasting with a number that was really never designed to predict delivery dates in the first place.
And it's not a team failure—it's more of a system failure. So it's okay if you're doing that, but let me talk about something that might take us to the next level called flow metrics.
How Flow Metrics Change the Conversation
Flow metrics can change the conversation for the better. They don't ask "how busy are we?" They ask "how does work move through the system?" When you have a lot of teams and cross-functional skills, that's an important thing to see.
Let me define a few terms we're going to be using all week in plain language that you're probably familiar with.
Work in Progress (WIP) is how many things are started but not finished. High WIP almost always means longer delays and more context switching. There's actually laws and studies on that.
Throughput is how many items actually finish per unit of time. Not started—actually finished.
Cycle Time is how long it takes for one item to go from start to done. This is basically what your customers feel, so it's a great metric.
Aging Work is how long current items have been in progress. I find aging work is a leading indicator of risks coming down the road.
When you track all of these items together, patterns emerge—real patterns, not wishful ones.
Why Flow Predicts Delivery Better Than Velocity
Data's great, patterns are great, but flow predicts delivery better than velocity. Delivery is a flow problem, not an effort problem, and flow metrics reflect those cues: the bottlenecks, dependencies, impediments, and interruptions. Velocity is just a lagging indicator of that.
This isn't just theory. There's a lot of great metrics and studies out there that we can use now that often weren't available 10 years ago. I'm going to refer to the 2024 DORA research that I've been blogging about for quite a while. This is one of those things that reinforces this point very clearly.
Teams that manage flow, limit work in progress, and reduce their cycle time variability tend to deliver more predictably and with higher quality outcomes. DORA shows that focusing on system health and flow can lead to better reliability and less burnout for developers as well—not just faster output.
Flow metrics are a lot harder to fake because they're grounded in reality. Work either moved or it didn't. You can't hide that. Somebody's going to know. Velocity can be gamed.
A Story About Rebuilding Trust
I want to tell a quick story here that happened recently. It may sound familiar and help you with your team in building trust.
I worked with a leadership team that had missed no less than three major delivery commitments in a row. I think it's actually more than that, but we'll go with three. The stakeholders were frustrated. The word "agile" had become a source of fatigue along with a lot of other buzzwords. The instinct is to promise harder—next time we're going to try better.
But instead I recommended we pause. I said, look, the team needs to go to the stakeholders and tell them this: "We've been giving you confident dates without enough evidence, and that's on us. So for the next 60 days, we're not going to promise delivery dates. We're going to show you the flow of the system and hold ourselves accountable—and you—to the impediments therein."
They started to share a lot of the dashboarding metrics that we built out for them. Things like work in progress limits. They showed cycle time distributions. They highlighted aging work and how those risks could surface at least weekly to help mitigate them.
What happened when we started doing that for 60 days is trust started to come back a lot quicker than the predictability did. And I want to talk about why.
Why Honesty Is Stabilizing
I think it's because honesty is stabilizing. When leaders stop defending the system and start revealing it, stakeholders lean in instead of pushing back.
A lot of times stakeholders aren't familiar with technology work. When we start using a lot of these words, they just don't get it. They're used to the traditional project management approach, and agile approaches things a lot differently. A lot of the friction is simply that they don't quite understand the problems we have in software development and technology development—which I go back to the beginning: we don't know if we solved your problem until we solve your problem.
We can plan all day long, but until we deliver it, engineer it, and push it somewhere where you can use it, we likely don't know. The iterative and incremental nature of delivery is an important part of that. Lean in and be honest about that.
What Leaders Should Start Asking
As this week unfolds across our blog and LinkedIn newsletter, and if you're subscribed to our emails, I'm going to start digesting what I want leaders to listen for:
Stop asking "when will it be done?" and start asking "what's stuck right now? Where are we stuck?"
Stop rewarding utilization of people and start rewarding flow and work finishing in our sprints or iterations.
Stop demanding certainty when there really is none. Start building credibility through transparency and honesty.
Flow metrics give leaders a language that's grounded. It's also calm, and it's adulting. We do this all the time with our families. We don't make an infinite amount of money every month, but somehow every month we have to get with our families and figure out where we're going to spend this money. Sometimes things happen that we didn't plan for. Now that's a little bit easier because the data's there and it's a little bit more hardened. But adulting is choosing things, choosing priorities—infinite list of things we could work on, finite amount of time and capacity to do them. Our stakeholders need something to help them adult better.
Better Evidence, Not More Confidence
If your organization is tired of broken promises, I promise the answer is not more confidence. I love confidence. I love metrics. I love data. But it's better evidence. The more of that you have, the better we can adult.
This week we're going to walk through how to start measuring flow in two to four weeks, how to stop the behaviors that create thrash in your team, and how to reset trust without blame.
If this resonates with you, stay with us this week. Share it with some colleagues—that always helps us out a great deal. Give us a like or a subscribe. And just remember that predictability without fantasy is possible, but only if we're willing to look at how work truly flows through the system. Then we can build on top of that.
Let's build credibility the honest way. See you next time.
Ready to transform how your teams deliver?Explore Big Agile's training classes to learn practical approaches for implementing flow metrics, rebuilding stakeholder trust, and creating predictable delivery systems.