Effort = Effort
The Broken Backlog Creation Nowadays
Here's something that keeps showing up across industries: planning departments (or portfolio) that don't talk to the people who actually build the product. And if they do talk, the information doesn't always make it into the plan.
Managers create quarterly plans. Executives approve roadmaps. Stakeholders sign off or promise timelines for delivery. And somewhere, three floors down or two time zones away, a developer team looks at the plan and says:
"Who came up with this? Have they ever seen our current work in progress? This is not possible!"
This isn't a tech problem. It's not an agile problem. It's a century-old management problem dressed up in Jira tickets and Sprint Reviews.
And it's where this story starts.
The "How Long Will It Take?" Trap
If you've ever been in a room where someone asks a development team "how much time do you need for this?", you know what happens next. The room gets quiet. Someone says "it depends." Someone else throws out a number that sounds reasonable but has no basis in reality. And the manager writes it down as a commitment. Even worse: the same question asked on another day, with another half of the team, would produce a completely different answer.
That's not planning. That's a system where the output has no connection to the input. How many times has anyone actually delivered quality on a timeline that was set without understanding the real effort involved?
Complex products, the ones that matter today, the ones that touch multiple systems, teams, and architectures, don't fit into a spreadsheet cell. You can't estimate your way out of complexity. And yet, every organization I've walked into tries exactly that: squeeze an uncertain, interconnected, multi-team effort into a neat quarterly plan. Then act surprised when it falls apart by week three. Or doesn't deliver three years down the road.
The answers you get are rarely based on data. They're based on gut feeling, on assumptions about expectations, on whoever speaks up first in the planning meeting. And that's not necessarily wrong. Estimates are estimates. They're uncertain by nature, and that uncertainty is fine, as long as the system handles it: consistent input, a shared way of estimating, and the willingness to revisit the plan as real data emerges.
Estimate, work, learn, re-estimate. That loop is what makes planning reliable over time, not the accuracy of the first guess.
But when that loop doesn't exist, when the first estimate becomes the commitment and nobody checks back, that's when decisions stop holding up. Not because of the people in the room. The system they're operating in doesn't give them what they need to decide well.
Year Three Of Five.
I learned this the hard way.
Back then I was coaching a team responsible for a core functional operating system. A product so central that if it failed, it would take the whole company down with it. They were in year three of a five-year development cycle, and they were running blind. And they were running out of time.
The team understood their domain and previous product inside out. But that expertise wasn't making it into the planning process. Instead, decisions came from above: plans made in rooms they weren't invited to, priorities set without visibility into the actual codebase or what it meant to the product.
They had Scrum. On paper, everything looked agile. They had Daily Stand-ups, Sprint Reviews, Retros. All the ceremonies, all the artifacts. But the backlog was a catastrophe. The Sprints were a mess. It was structured for a simple product (Epics and Stories in Jira), not for a complex, multi-layered operating system with dependencies reaching into every corner of the organization, as well as external providers. Multiple of them.
The dependencies were immense. The politics were big. The silos were bigger.
And the pressure? If this product wasn't ready by year six, almost 6,000 jobs would be on the line. Entire production chains were dependent on this working.
That's not a hypothetical. That was the actual situation. Real people. Real consequences.
The Scrum Exorcism
Something had to change. Not incrementally. Fundamentally.
What happened next is what I now lovingly call: a Scrum Exorcism.
Not because Scrum is bad. It isn't. But the framework wasn't the point. The point was that the planning system couldn't make effort visible. The backlog was structured for a simple product, not for a complex operating system with dependencies reaching everywhere. And no framework, whether Scrum, LeSS (Large-Scale Scrum), SAFe (Scaled Agile Framework), or anything else, would fix that on its own.
What the system needed wasn't a better framework. It needed three things: measurability, transparency, and self-organization. Kanban became the foundation for that. The team took a leap of faith, because time was running out.
We needed to see where work actually was, not where people said it was. We needed to understand how long things actually took, not how long someone wished they would take. And we needed the people closest to the work to make decisions about the work, instead of waiting for permission from three levels up.
The Product Owner’s and the Department Head were drowning. One person, trying to manage a backlog that was way too big, way too tangled, and way too political for any single human to handle and another person trying to align priorities, incremental dependencies and stakeholder expectations. So we distributed the responsibility: to the people who actually understood the work, while being aligned with the department’s needs.
Can you guess where we started having Initiative Owners?
The Big Picture
This is where it got real.
Developers started owning initiatives. Not as a formal role, but as a shift: the same expertise that hadn't been part of the planning process was now driving it.
Their job wasn't to manage sprints or write user stories. Their job was to look at the big picture: identify the rough scope and effort of an initiative. Not just for their own team, but across entire departments. Because here's the thing that everyone knows but nobody acts on:
Effort is effort. No matter where it sits, who it belongs to, or when it has to be done.
If your initiative needs backend work, frontend work, infrastructure changes, a third-party integration, or even just writing an email to a different department: that's the effort. All of it. You don't get to pretend the backend team's work doesn't count because "that's their problem." If backend and frontend don't work together, you don't have a product. Period.
This sounds obvious. It is obvious. And yet, almost every organization I've worked with plays the same game: "We're only responsible for X” As if dependencies disappear when you refuse to look at them.
What changed was the visibility. When you map out the actual effort across all teams and systems, the prioritization conversations shift on their own. Instead of "what was promised, and by when?" it becomes "what do we actually need to do, no matter the department or team?"
6 days average per ticket, all roughly the same size. And when one took 5 weeks? More than half of that time was spent blocked or waiting for feedback. Not a work problem. A system problem. For the first time, this team could answer 'when will it be done?' with data, not a gut feeling.
The Principle Behind It All
The pattern had been there before. But this was the situation where it became impossible to ignore. And the principle that emerged was simple:
Effort = effort. No matter where, who it belongs to, or when it has to be done.
It means: stop pretending that effort in another team doesn't count. Stop planning as if your product lives in isolation. Stop asking developers "how long?" and start asking "what's the full picture? What happens before and after?"
When you take this seriously, when you actually map all the effort, across all the teams, across all the dependencies... you can finally make decisions based on reality instead of assumptions.
The team that was running blind in year three? They started seeing. Not because the plan got better, but because the system finally made the real picture visible.
What This Means For Your Crew
If you're reading this and thinking "that sounds exactly like us": you're not alone. The pattern keeps showing up, regardless of industry or product.
The question is whether the people who understand the work are the ones making decisions about it, or whether they're still waiting for a quarterly plan that was built without their input.
The answer usually starts with visibility.
If you want to explore what it would look like to turn your planning upside down, or rather, right side up: get in touch!