How AI-assisted sprint planning cut project overruns by 45%

The project that was always two weeks behind

I've worked with engineering teams where sprint overruns were so routine they'd stopped registering as events. Every sprint ended with 20 to 30% carryover. The plan got revised monthly. Stakeholders had stopped trusting delivery estimates. The engineers had stopped believing the plan meant anything at all.

This is not a capability problem. It's an information problem.

The warning signs were always there before each overrun. Velocity sliding for three sprints in a row. An engineer mentioning an unexpected complexity in passing during standup. A dependency on an external API that was moving slower than anyone had estimated. The information existed. Nobody was pulling it together into a coherent early warning.

That's the problem AI-assisted project monitoring is built to solve.

The context: a complex multi-team fintech delivery

The engagement involved a fintech platform with three engineering teams: a core API team, a data and analytics team, and an integrations team. The project was a major platform extension with external regulatory implications, so the delivery timeline didn't bend.

The project looked like this:

14-week delivery timeline, externally committed
3 teams, 18 engineers total, distributed across two time zones
7 external dependency touchpoints (vendor APIs, regulatory sandbox access, third-party testing)
Complex interdependency graph: integrations team dependent on core API team at multiple points

The team's prior delivery history: a 68% on-time sprint completion rate. By their own track record, this project was already behind before it started.

What we built: the AI project intelligence system

I introduced a lightweight AI monitoring layer that sat on top of the existing Jira and Azure DevOps setup. It had four components.

Component 1: automated dependency extraction

The team's Jira tickets carried dependency information in the description and comment fields, written in plain language, never formalized in Jira's dependency graph. An LLM-based parser read every ticket weekly and extracted:

Explicit dependencies ("blocked by ticket X")
Implicit dependencies ("requires the auth service to support the new token format")
External dependencies ("waiting for vendor to provide sandbox credentials")

The extracted dependencies went into a structured graph the PM could see and act on.

In the first week alone this surfaced 23 dependencies that weren't in the formal Jira graph. Invisible risks, every one a potential blocker.

Component 2: velocity anomaly detection

A time-series layer tracked each team's velocity against its historical baseline and against the current sprint plan:

Velocity Monitor - Week 5 Report:
----------------------------------
Core API Team:
  Sprint velocity: 38 points (baseline: 52, plan assumption: 50)
  3-sprint trend: -8% per sprint (declining)
  Projected completion at current velocity: Week 17 (plan: Week 14)
  Alert: YELLOW - trending below plan threshold

Data & Analytics Team:
  Sprint velocity: 49 points (baseline: 47, plan assumption: 48)
  3-sprint trend: +2% per sprint (stable/improving)
  Projected completion at current velocity: Week 13.5 (plan: Week 14)
  Alert: GREEN

Integrations Team:
  Sprint velocity: 31 points (baseline: 44, plan assumption: 42)
  3-sprint trend: -15% per sprint (significant decline)
  Projected completion at current velocity: Week 19 (plan: Week 14)
  Alert: RED - immediate attention required

The week 5 report flagged a serious problem: the Integrations Team was tracking to deliver in Week 19, not Week 14. A 5-week overrun that would have been painfully obvious by Week 12. Catching it in Week 5 gave us 7 weeks to do something about it.

Component 3: stakeholder communication sentiment analysis

The PM was spending a lot of time in status calls with external stakeholders. I added a post-meeting analysis step. An LLM processed each meeting transcript and pulled out the open commitments the team had made, the open concerns stakeholders had raised and not had resolved, and the sentiment trend: was the relationship stable, improving, or sliding?

This gave the PM a structured record of every status meeting, which previously lived only in handwritten notes, and it caught stakeholder concerns that were being raised politely but never formally escalated.

Component 4: sprint completion probability reporting

Each week, the system generated a sprint completion probability report using Monte Carlo simulation over the remaining sprint backlog:

graph LR
    subgraph INPUTS["Inputs"]
        VEL[Historical Velocity Distribution]
        BACK[Remaining Backlog - estimated points]
        DEP[Open Dependencies - unresolved count]
        EXT[External Risks - flagged items]
    end

    subgraph SIM["Monte Carlo Simulation - 10,000 runs"]
        SIM1[Sprint Completion Distribution]
        P50[P50 - 50% confidence date]
        P80[P80 - 80% confidence date]
        P95[P95 - 95% confidence date]
    end

    subgraph OUT["Weekly Report"]
        DASH[PM Dashboard]
        ALERT2{Alert Level}
        RECO[Recommended Actions]
    end

    VEL --> SIM1
    BACK --> SIM1
    DEP --> SIM1
    EXT --> SIM1
    SIM1 --> P50
    SIM1 --> P80
    SIM1 --> P95
    P50 --> DASH
    P80 --> DASH
    P95 --> DASH
    P95 --> ALERT2
    ALERT2 --> RECO

The PM read this report every Monday. It replaced the gut feel that used to decide whether a schedule concern was worth escalating.

What the system caught

Over the 14-week project, the monitoring system surfaced three real risks before they hardened into blockers.

Week 5, the Integrations Team velocity drop. Root cause: two senior engineers on the team had been quietly pulled onto a separate internal project, cutting their effective sprint capacity by 30%. The reassignment was undocumented and invisible to the PM. Caught in Week 5, resolved by Week 6 through reallocation.

Week 7, a hidden dependency on the Core API timeline. The dependency extraction found 6 Integrations tickets that implicitly depended on a Core API feature not yet in the Core API sprint plan. Left alone, the Integrations team would have slammed into a hard blocker in Week 10. It went onto the Core API plan in Week 8.

Week 11, a stakeholder concern surfacing. Sentiment analysis of the Week 11 status call picked up growing uncertainty from a key external stakeholder about the UAT timeline. The PM had read the call as positive. The transcript analysis flagged four specific statements that said otherwise. A follow-up call in Week 12 revealed the stakeholder's internal timeline had shifted. Managed early instead of discovered in Week 13.

The results

Metric	Previous 6-Month Baseline	During 14-Week Project
Sprint on-time completion rate	68%	91%
Sprint overrun percentage	avg. 28% carryover	avg. 9% carryover
Risks identified before becoming blockers	retrospective only	3 of 3 major risks
PM time on status reporting	~8 hrs/week	~3 hrs/week
Project delivered on time	N/A	Yes - Week 14

The 45% drop in sprint overruns, from 28% average carryover to 9%, is the headline number. But the part that may matter more doesn't fit in a table. For the first time in this team's recent history, a major delivery landed on schedule. The stakeholder relationship recovered. The team started trusting its own estimates again.

What this required from the PM

The PM on this project wasn't replaced or scaled down. The hours they got back from status reporting went into the work AI can't do: building relationships, navigating the organizational politics around the team reassignment, and making the judgment call on how to put the Week 11 stakeholder risk in front of leadership.

The AI processed the information. The PM used it to manage better.