How to Account for Dependencies in Software Project Estimates

By The Quely Team — Quely editorial team

A startup once estimated it would take two days to add what looked like a trivial UI tweak, a toggle to their dashboard. Front-end work was estimated at two days.  What the team overlooked was that this dashboard relied on an authentication microservice owned by a separate team, one that happened to be knee-deep in a security audit. Two days turned into two weeks and stakeholder frustration increased.

We made up this story but the truth is, you can relate to it. Most times, you underestimate how your work depends on other teams, third-party APIs, and so on which stall progress. In this article, you’ll learn how to recognize, size, and account for dependencies in your project estimates.

The Cost of Invisible Dependencies

Dependencies that aren’t accounted for don’t just delay your sprint; they erode trust with stakeholders and frustrate customers. When you promise “two days” and deliver two weeks, every subsequent estimate is met with skepticism. You risk:

  • Customer churn: Missed deadlines on visible features directly impact satisfaction.

  • Team morale dips: Repeated firefights against unseen blockers exhaust engineers.

  • Leadership fatigue: Product leaders lose confidence in roadmaps, slowing decision cycles.

To escape this, we need a systematic way to identify, estimate, and ultimately reduce dependencies. Here is how you can do that:

How Quely Helps Teams Identify Dependencies Before Estimating

Quely is an intelligence layer across connected systems. It brings execution objects such as Jira issues into a Space as Work Units and connects them with the context Orbit needs to reason about dependencies.

  1. Bring work into a Space: Jira issues and other tasks enter the Space's Queue as Work Units while retaining native details such as status, ownership, priority, due dates, comments, and metadata.

  2. Ask Orbit about dependencies: Orbit reasons across Work Units, relationships, historical activity, and connected context to identify gaps that a single ticket may not reveal.

  3. Review the Signals: Questions, risks, blockers, assumptions, and dependencies become Signals that the team can examine before committing to an estimate.

  4. Refine the estimate with context: Estimation remains a workflow around the Work Units. The estimate improves because the team can see the relevant relationships and unknowns, not because a tool produces a number without explanation.

  5. Check responsibility and capacity: Ownership shows current responsibilities, commitments, team workload, and available capacity so dependent work can be scheduled without quietly overloading a team.

Explore how Orbit turns connected context into actionable understanding.

Methods for Handling Dependencies

Dependencies can sneak up on your sprint plan and derail delivery. But with the right methods, you can turn them into predictable, manageable parts of your process. Below is a streamlined playbook that blends tactical accounting with strategic elimination, packed with examples and decision checkpoints to guide you.

A. Tactical Methods: Estimating with Dependencies Built In

  1. Split vs. Include the Shared Work
    The first recommendation is having two clear options for stories that share infrastructure or technical work:

    • Include the shared effort in each story’s estimate. Both Story A and Story B carry the cost of the shared work in their story points, ensuring no gap if the order flips.

    • Pull out the shared work into its own “technical” story delivered first. Downstream stories then assume the dependency is fulfilled, avoiding double-counting.
      Owens warns “don’t estimate A assuming B is done without making it explicit,” because if the order changes, you’ve unknowingly under- or over-estimated one story

  2. Maintain Sequence Integrity
    Mike Cohn of Mountain Goat Software advises estimating with the “natural order” in mind so that the sum of your estimates equals the real total effort of doing both features in sequence—no more, no less. If your team ends up working in a different order, a quick reallocation of a few points between the overlapping stories keeps your backlog’s total honest and your sprint forecasts accurate.

  3. Three-Point Estimates & Buffers

    • Capture Optimistic (O), Most Likely (M), and Pessimistic (P) durations for any task with significant dependencies.

    • Compute a weighted average:
      (O+4×M+P)÷6(O + 4×M + P) ÷ 6(O+4×M+P)÷6

    • Model schedule risk instead of applying a universal buffer. Estimate the likelihood and impact of specific dependencies, then derive contingency from that analysis. The U.S. GAO Schedule Assessment Guide explains how schedule risk analysis supports realistic completion dates and the cost effects of slippage.

  4. PERT for Complex Webs
    For large, multi-team projects, the Program Evaluation and Review Technique (PERT) brings structure to your work:

    • Diagram every task and its dependencies in a network chart.

    • Apply three-point estimates to each node.

    • Calculate the critical path and focus your contingency where it truly matters.
      Teams using PERT report more accurate overall schedules on dependency-heavy initiatives, trading a bit of upfront modeling time for far fewer surprises later.

B. Strategic Methods: Eliminating Dependencies at the Source

I am convinced that dependencies need to be eliminated, not managed
Ilia Pavlichenko

  1. Reorganize into Feature Teams: Instead of handing off work to component teams (e.g. a backend squad and a frontend squad), form cross-functional groups that carry features from end to end. Shared ownership dissolves hand-offs and makes estimation more straightforward .

  2. Simplify Your Architecture: Fragile libraries and monolithic services force constant coordination. By refactoring into modular microservices with clear contracts, you shrink the web of dependencies and regain velocity.

  3. Automate Manual Gates: Manual security reviews or compliance sign-offs often add days of delay. Automate linting, tests, and approval workflows in your CI/CD pipelines so that what once took three business days now finishes in minutes.

  4. Treat Dependencies as Red Flags: Mark Taylor, host of the Better ROI from Software Development podcast, argues that dependencies are nearly as impactful on your schedule as overall feature size and uniquely troublesome because they’re outside your immediate control. When your planning process surfaces an external dependency, use it as a signal to ask if you can we remove or reassign this work rather than merely estimate the wait?. This elimination-first mindset prevents layers of buffers from turning your roadmap into a padded, unrecognizable blob.

Conclusion

Dependencies do not have to be the stumbling blocks that derail a project. When Work Units and their connected context are organized inside a Space, Orbit can surface cross-team dependencies, blockers, risks, and unanswered questions before the team commits to a plan.

Use those Signals to refine the estimate, then use Ownership to check responsibility, commitments, workload, and available capacity. Explore Orbit to see how connected context becomes actionable understanding.

Related reading: Build more defensible sprint estimates.