Estimating development timelines for features and integrations: how to calculate

Why estimates break on integrations

Estimates can look neat for features, and the deadline still slips. A common reason is simple: the team counted only their code, while the integration follows the external system’s rules. In the end, “our part is ready” but the release is delayed by waits, approvals and partner constraints.

Integrations differ from regular development because there’s an area you don’t control: procedures, incomplete docs, unstable test environments, queues for changes and sometimes conflicting team interests. So an estimate should include not only the code, but all the steps around it.

Most often people forget things that don’t look like "developer tasks" but can easily eat weeks: getting accesses and certificates, waiting for a test environment and data, clarifying API contracts (formats, versions, encodings), joint checks and re-runs, and release time constraints (for example, only at night or on weekends).

This hits especially hard on projects with many external dependencies: data migrations, connections via buses and message brokers, reports and data marts from multiple sources. One “small change” becomes a chain: changed a field in the source → updated mapping → rebuilt load → rechecked reports → acceptance again.

A simple example: you build a new application form and the form itself is ready in a few days. But if the application status must go to an external accounting system and return, the real timeline depends on accesses, test environment stability and the number of correction cycles after the first integration tests.

Feature, integration, migration: let’s agree on terms

To keep estimates from turning into arguments, name things the same way first. It helps to separate work into three entities:

• Feature — what changes for the user.
• Integration — how the system interfaces with the outside world.
• Migration — what happens to the data.

Fix feature boundaries in one paragraph, without “and a little more”. A working template: “User X will be able to do Y in system Z to get result W. Out of scope: A, B.” If it doesn’t fit in one paragraph, it’s probably several features.

Treat any exchange with an external system or process that affects timing and testing as an integration: APIs and webhooks, scheduled file transfers, queues and events, SSO and authorization, and manual steps between systems (operator actions, approvals, phone calls).

List migrations and data changes separately, even if they seem “small”. Adding a field, recalculating a reference, migrating history, deduplication, changing access rules — these are separate tasks with their own risks.

At the end, agree on "done" criteria for all three parts. For a feature — user scenarios and constraints. For an integration — which data moves when, what counts as an error and how it’s visible. For a migration — source and destination, volume and verification method. If these criteria are not fixed before estimation, timelines will start drifting at the level of wording.

Inventory of external dependencies

Integrations with external systems rarely “just plug in.” Calendar time is usually eaten by waits: someone must grant access, confirm data schema, open network rules, or stand up a test environment.

Collect a registry of all external systems the feature touches: payment gateway, government service, LDAP/AD, warehouse, BI, mailing service, third-party CRM. For each dependency record not only the name but the people and rules around it.

Mini dependency passport

Keep a short card for each dependency:

• system owner and the decision contact
• environments (prod, test, sandbox) and how to access them
• support windows and expected response times
• what to request in advance: accesses, keys, test data
• limits: API quotas, security and compliance requirements

Then check what actually affects the schedule. For example, security may require IP and certificate approvals, and API limits add work for queues and retries. If the partner has no test environment, allocate more time for careful checks and coordinated test windows.

To avoid dropped actions between teams, make a simple matrix of “who waits for what from whom.” It quickly shows where queues form and why the initial estimate was too optimistic.

How to break an integration into estimable work

An integration is almost never “connect the API and done.” For an honest estimate, break it into small verifiable pieces that can be closed sequentially.

Start with blocks that almost always appear: requirements clarification, development, environment setup, approvals. The key is to write down in advance exactly what travels between systems and how it can fail.

For each integration capture the minimum that will become tasks and hours:

• Inputs and outputs: fields, formats, requiredness, constraints.
• Errors: codes and messages — what the user sees, what goes to logs.
• Timeouts and retries: how long to wait, when to retry, when to give up.
• Duplicates and idempotency: what to do if an event arrives twice.
• Security and accesses: keys, roles, IPs, certificates, who issues them and when.

Logging and monitoring should be listed separately. Without them an integration “works” only in demo and in production becomes endless investigations.

Don’t forget the external side. If the partner must change something (add a field, enable a method, set up an export), this is not an abstract risk but concrete expectations about their releases and change windows.

Example: connecting payments. Besides the “create payment” request you’ll have cancellations, repeated notifications, status reconciliation, test keys, logs for disputed transactions and format agreements with the bank. These details make the timeline realistic.

Step-by-step method for estimating by features and integrations

Collect a single list of work: features, integrations, migrations, reports, mandatory technical tasks for the release. It’s important the list is one place, otherwise work disappears between teams.

For each item briefly describe scenarios: the main path, what happens on error, what happens if data is missing, which roles and permissions are involved. A couple of edge cases often add days, not hours.

Then estimate each item by layers. This breakdown helps find gaps and prevents arguing in general terms:

• code and logic (API, UI, error handling)
• data (schemas, mapping, migration, cleaning)
• infrastructure (environments, secrets, queues, monitoring)
• processes (procedures, runbooks, training, support)

Also create tasks for approvals and waits: accesses, test accounts, responses from external system owners, security reviews and legal approvals. These tasks have calendar time even if “there’s little work.”

Final step — reconcile the estimate with the calendar. Are there partner release windows, bans on changes at month-end, procurement lead times, key people on vacation? An integration can be “5 workdays” but become “3 calendar weeks” because of one approval and a single deployment window.

How to account for data migrations without surprises

Migration is rarely just “dump the tables.” Surprises come from dirty data, rules that changed over years, and integrations expecting strict formats. So treat migration as a set of works: preparation, runs, verification and the switch.

First assess data quality and readiness. Agree on rules: which records are considered active, how to merge duplicates, how to treat empty fields, which reference tables are authoritative. These decisions take time and require data owners’ involvement.

Allocate at least one run on a test environment. Almost always a second run is needed after mapping fixes, schema changes or found exceptions. Agree in advance on metrics and reports to verify results.

To avoid the “too late to cancel” trap, plan rollback steps, result verification (checksums, spot checks, reports), switch windows, freeze periods in the old system and external system constraints (limits, locks, availability schedule).

Example: moving customer data to a new CRM often fails not because of volume but because of deduplication, unified naming rules and a short switch window when sales cannot pause for long.

Estimating testing and acceptance for integration tasks

Integrations often break schedules not because of code, but because of checks. Count testing as a separate set of works, not “we’ll test later.” A practical minimum is to split checks into unit, integration and end-to-end: they have different costs and risks.

For external systems add scenarios often missed: API errors, unavailability, timeouts, queue delays, different data formats. If you test only the happy path, surprises will arrive during acceptance.

A separate time item is environments and test data. The integration can be ready but untestable: no test contour, accesses not issued, accounts not created, data cannot be used from production. Agree up front who prepares the environment and include that in the plan.

To make the estimate honest, write the QA and acceptance minimum: prepare test data and accounts, set of scenarios (success, errors, retries, partial data), integration tests with artifact collection, end-to-end runs through all systems and time for fixes with retests.

Acceptance itself needs estimating. Decide in advance who signs off, by what criteria and how many fix cycles are allowed. For example, after the first run an external system may respond more slowly, requiring timeout and retry tuning and extra logging — another full cycle of testing and agreement.

Time for communications, accesses and environments

Integrations often slip not because of code but because of waits. Accesses, approvals and environment preparation go through people and processes, not your backlog. Treat them as separate work items.

The most common blocker is queues for changes and access. Security teams may take days to review requests, admins schedule work in windows, and the external system owner may reply “after our release.” Add explicit tasks for requests, confirmations and waits with a clear owner and expected response time.

What to include in estimates

Usually four blocks surface:

• Accesses: VPN, accounts, roles, log access, test environment access of the external system.
• Environments: test stands, variables, certificates, keys, app registrations, network rules.
• Agreements: data formats, API contracts, versions, limits, error handling and retry policies.
• Schedule: release windows, freeze periods, dependency on parallel teams.

How to handle release conflicts and parallel teams

If two teams change the same API, you wait not only for access but for someone else’s release. In plans reflect this as a separate “external wait” plus a buffer for rescheduling.

Practice: at start ask each external party for two numbers — typical time to provide access and the next release window. These immediately become calendar constraints.

Risks and buffers: how to add them fairly

Integrations almost always surprise, so buffers are not a fuzzy cushion but an explicit recognition of uncertainty. Show where contingency comes from and what it covers.

It helps to split risks by type:

• technical (unstable API, quotas, queues, format incompatibility)
• organizational (no system owner, slow access approvals, contractor delays)
• calendar (release windows, holidays, freeze periods)

Simple rule: place the buffer next to the source of risk, not as a single number at the plan’s end. If the risk is in accesses — add slack to the “get access and check environment” task. If the risk is data quality — add it to the “verify and clean data” block.

To make the discussion concrete, use three estimates for each integration block: optimistic, realistic and pessimistic. Use the realistic as the base plan. The gap between realistic and pessimistic becomes a manageable buffer.

Also reserve time for unknown integration errors. This is not “fix bugs in general” but a reserve for debugging on real data and in the real contour after the first end-to-end check.

Common estimation mistakes

Schedule failures usually happen not because of the feature but because surrounding integration, waits and acceptance were not counted.

Most frequent mistakes:

• Treating integration as a single task “connected the API.” In reality there are scenarios, errors, limits, retries, logs, monitoring and sometimes manual processes.
• Not allocating time for test data, environments and accesses.
• Not accounting for the external party’s waits: issuing keys, changes in their system, switch windows and security approvals.
• Ignoring migrations: preparation, test runs, result verification and rollback planning.
• Mixing development and acceptance into one phase.

Example: adding payment. The team estimated 5 days of code but didn’t consider that the bank issues accesses in 3 days, test cards are provided via support, and callback addresses are enabled only in a specific window. Five days become two calendar weeks.

A simple rule set: split integration into scenarios (success, cancel, timeout, retry, manual handling), estimate environment preparation separately, explicitly include external waits and fix acceptance control points.

Example: a feature with two integrations and a small migration

Imagine a feature: a new order status appears in the internal system, e.g. “Ready to Ship.” It must be sent to two external services: (1) ERP for accounting, (2) delivery service for creating a pickup order. At the same time update reference data (delivery types, warehouses) and carefully migrate history for existing orders.

Timelines expand not because of the “button code” but because of integration details. You quickly find you need accesses and test accounts, data formats differ, and errors must be handled so nothing gets lost.

What usually adds time

Hidden work surfaces: retries after timeouts, request and response logs, field and reference reconciliation, criteria for “exchange works correctly.” Plus environments: the partner’s test contour may be unstable and ERP change windows may be scheduled.

Where the migration appears

Even a “small” migration commonly includes references (warehouses and tariffs), statuses (mapping old values to new ones) and history (what to do with completed orders and events). Decide in advance whether to migrate all data or only active records for the last N days, and how to verify.

A calendar plan often looks like: 1–2 days for accesses and initial agreements, 2–4 days for the first integration (formats, errors, logs), 2–4 days for the second, 1–2 days for a migration script and run, then 2–3 days for integration testing and acceptance. On paper that’s “two weeks,” but waits (accesses, format answers, deployment windows) easily stretch it to three.

A sign an estimate is too optimistic: no confirmed answers to “where do we test”, “who provides access”, “what are error codes and SLAs of external services”, “how do we roll back”. If these are open, add time for the unknowns.

Short checklist and next steps

Before naming dates, run quick checks:

• which external systems are involved and who owns them
• where and how we test (contours, data, accounts)
• what happens to data (migrations, required fields, quality)
• who accepts the result and by what criteria
• what constraints exist from external sides (limits, security, change windows)

To keep discussions focused, create a mini-template per integration: scenarios (success and failure), request/response formats, typical errors and how they’re shown to users, minimal test set and responsible people on both sides.

A 60–90 minute estimation session works well like this: goals and boundaries, then scenarios and data, then risks and dependencies, then tests and acceptance, and finally record assumptions and next steps. The outcome should be not a pretty number but a list of works and open questions.

For the release, predefine the deployment window, rollback steps, on-call responsibilities and control points after launch (what to check in the first 30 minutes and the first day).

If you have many external contours and participants, involve an experienced integrator. GSE.kz (gse.kz) does system integration and infrastructure solutions, including environment preparation and rollout support, which helps eliminate common risks around accesses, test stands and acceptance in advance.