If you've worked on a software team long enough, you've probably experienced this.
Sprint planning goes well. The team breaks down a feature into tasks, estimates each one, assigns owners, and everyone leaves the meeting feeling confident.
A few days later, reality hits.
A backend change requires a database migration nobody considered.
The frontend team is blocked because an API isn't ready.
QA discovers edge cases that require additional implementation.
Another developer is waiting on work from someone in a different team.
Suddenly, the original sprint plan no longer reflects reality.
Sound familiar?
For a long time, I thought this was simply part of software development. But after seeing the same problems across multiple projects, I started wondering:
What if we're trying to manage software using the wrong model?
The Problem Isn't Estimation
One of the biggest discussions in Agile teams is estimation.
Should we estimate using story points?
Hours?
Planning Poker?
Velocity?
Yet, no matter which method we choose, estimates are often wrong.
Not because developers can't estimate.
But because you can't estimate work that you don't know exists yet.
Every project contains unknowns.
As development progresses, new requirements appear.
Hidden dependencies are discovered.
Technical limitations surface.
Someone realizes another service also needs changes.
A task that looked like "three days" suddenly becomes "two weeks."
The estimate didn't fail.
Our understanding of the work changed.
We Plan Tasks Instead of Understanding Features
Today's project management tools are excellent at tracking tasks.
A typical feature might look like this:
Login Feature
• Backend API
• Frontend UI
• Database
• Testing
• Documentation
This answers one question:
What needs to be done?
But software development is rarely about individual tasks.
It's about how those tasks interact.
Questions like these are much harder to answer:
- Which task is blocking mine?
- If my task is delayed, who else is affected?
- Which developer depends on another developer?
- How many teams are involved in this feature?
- Are we actually close to finishing?
To answer those questions, we usually have to search through Jira tickets, comments, Slack conversations, and meetings.
The information exists.
It's just scattered.
Software Is a Network
A feature isn't a checklist.
It's a network.
Take something as simple as a login feature.
It might involve:
- UI
- Backend API
- Authentication
- Database
- Session Management
- Security
- Monitoring
- Testing
- Deployment
None of these exist independently.
They depend on each other.
Instead of looking like this:
Login Feature
□ Backend
□ Frontend
□ Database
□ Tests
It actually looks more like this:
Feature Map
Feature
/ | \
API UI Database
| | |
Auth Forms Migration
\ | /
Integration Tests
|
Deployment
This tells a completely different story.
Instead of seeing isolated tasks, we see relationships.
And relationships are what determine whether a project moves forward or becomes blocked.
Hidden Dependencies Cost More Than Bad Estimates
Most sprint failures aren't caused by someone estimating four days instead of five.
They're caused by discovering work too late.
For example:
"We forgot the migration."
"The mobile app also needs changes."
"Ops needs monitoring before deployment."
"This API change affects another team."
These aren't estimation errors.
They're visibility problems.
If these dependencies had been visible from the beginning, the plan would have been completely different.
A Missing Layer: Feature Maps
I believe we're missing something between planning and implementation.
Instead of representing a feature as a list of tickets, what if we represented it as a dependency graph?
I call this idea Feature Maps.
Each node represents a piece of work.
Each connection represents a dependency.
Every node knows:
- Who owns it
- What it depends on
- What it blocks
- Its current status
- Its progress
Instead of opening twenty Jira tickets to understand a feature, the relationships become immediately visible.
The map becomes the feature.
The tickets become implementation details.
"Done" Should Mean More Than Closed Tickets
One thing I've noticed is that teams often say a feature is 90% done.
But what does that actually mean?
Imagine instead that completion is structural.
Login Feature
✅ UI
✅ Backend
✅ Database
✅ Authentication
✅ Testing
❌ Monitoring
❌ Documentation
❌ Deployment
The feature isn't complete until every required component is complete.
No assumptions.
No forgotten tasks.
No surprises before release.
Better Planning Starts With Better Visibility
This idea isn't about replacing Agile.
Agile helps teams organize work.
Issue trackers help teams execute work.
But neither gives us a complete picture of how the work connects.
When developers understand the full network of dependencies, something interesting happens.
Missing work is discovered earlier.
Blocked tasks become obvious.
Communication becomes easier.
Estimates naturally improve—not because people became better at guessing, but because the team has a better understanding of the problem they're solving.
Looking Forward
As software systems become larger, our planning tools haven't evolved much.
We still represent complex systems as flat lists of tickets.
But software isn't a list.
It's a living network of services, people, teams, and dependencies.
Maybe the next evolution of project management isn't another estimation technique.
Maybe it's changing how we visualize work.
Maybe before asking "How long will this take?", we should first ask:
"Do we actually understand everything this feature depends on?"
I'd love to hear your thoughts.
Do you think today's tools give enough visibility into dependencies, or is there room for a different way of planning software?
example:
A Real-World Example
Let's imagine a team is building a new User Authentication feature.
During sprint planning, the work is broken down into Jira tasks like this:
AUTH-101 - Create Login API (Bob)
AUTH-102 - Build Login UI (Carol)
AUTH-103 - Database Migration (Alice)
AUTH-104 - JWT Authentication (Bob)
AUTH-105 - QA Testing (David)
AUTH-106 - Deployment (Emma)
Everything looks organized.
Each task has an owner.
Each task has an estimate.
The sprint begins.
Three days later, reality starts to diverge from the plan.
- Carol (Frontend) can't finish because the Login API isn't ready.
- Bob discovers the API requires changes to the database schema.
- Alice realizes the migration is more complex than expected.
- David (QA) is waiting for both the frontend and backend.
- Emma (DevOps) can't deploy until QA is complete.
Everyone starts asking questions:
- "What's blocking the API?"
- "Can I start my work yet?"
- "Who's waiting on me?"
- "How much of this feature is actually finished?"
The answers exist—but they're scattered across Jira comments, Slack messages, stand-up meetings, and people's memory.
The project isn't missing information.
It's missing visibility.
The Same Feature as a Feature Map
Now imagine the feature is represented as a living dependency graph instead of a flat list of tickets.
Authentication Feature
│
┌──────────────┬──────────────┐
│ │ │
Database Backend API Frontend UI
(Alice) (Bob) (Carol)
│ │ │
Migration JWT Authentication │
└──────────────┼──────────────┘
│
QA Testing
(David)
│
Deployment
(Emma)
At a glance, everyone understands how the work is connected.
Carol knows she's waiting for Bob.
Bob knows he's blocked by Alice.
David knows QA cannot begin until both frontend and backend are complete.
Emma immediately sees why deployment hasn't started.
No searching through dozens of tickets.
No asking the same questions during every stand-up.
The Project Changes...
Now imagine Bob discovers something unexpected.
The authentication service also requires a Token Refresh Service that wasn't identified during planning.
Instead of creating another disconnected ticket, Bob adds it directly to the Feature Map.
Backend API
│
JWT Authentication
│
Token Refresh Service 🆕
│
Session Manager
Immediately, the entire team can see:
- A new task has appeared.
- Bob owns it.
- It blocks frontend integration.
- QA will also be delayed.
- The feature isn't as close to completion as everyone thought.
The team's understanding evolves the moment the project evolves.
Status Isn't Enough
Most project management tools track only one thing:
In Progress
But "In Progress" doesn't tell the team very much.
Instead, every node in the Feature Map could expose its health.
Task:
Database Migration
Owner:
Alice
Status:
In Progress
Health:
🟡 At Risk
Reason:
Unexpected schema conflicts with production data.
Blocks:
Backend API
Or:
Task:
Backend API
Owner:
Bob
Status:
Blocked
Reason:
Waiting for Database Migration.
Blocks:
Frontend UI
QA Testing
Or:
Task:
Frontend UI
Owner:
Carol
Status:
Ready
Health:
🟢 Healthy
Waiting For:
Backend API
Progress:
80%
Now the conversation during the daily stand-up changes.
Instead of saying:
"I'm still working on AUTH-102."
The update becomes:
"The Backend API is now blocked by a database issue. This affects Frontend, QA, and Deployment. I also discovered a new Token Refresh task that needs to be completed before authentication is finished."
That's much more valuable.
The Missing Piece Isn't Better Estimation
Software projects don't fail because developers estimate poorly.
They struggle because our understanding of the project changes every day, while our planning tools remain static.
A Feature Map becomes a living representation of the project.
It doesn't just show what people are working on.
It shows how everyone's work is connected, what's blocking progress, where new work has appeared, and how changes affect the entire team.
In my opinion, that's the missing layer between planning and implementation.
Top comments (0)