Software Isn't a List of Tasks—It's a Network of Dependencies

Moein Hosseini — Sat, 04 Jul 2026 06:02:40 +0000

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.

DEV Community: Moein Hosseini