Featured

Beyond Dashboards: Why Your Internal AI Tool Can Tell You Cycle Time is Up, But Can’t Tell You How to Fix It

Discover why internal DIY dashboards and basic LLM wrappers just create 'noise.' Learn how Keypup’s NLP platform goes beyond plotting metrics to actively diagnose your SDLC bottlenecks and prescribe actionable improvements.

Stephane Ibos LinkedIn

May 11, 2026 • 8 min read

If you spend any time browsing engineering leadership forums, you’ll quickly notice a recurring theme of profound frustration regarding engineering metrics.

Consider this highly relatable complaint recently posted on Reddit’s r/devops:

Reddit (r/devops)

"Management had us spend three weeks building an internal dashboard to track our DORA metrics via GitHub and Jira APIs. Now, every time Lead Time for Changes goes up, there's a panic. The dashboard tells us we're slower, but it doesn't tell us why. It’s just noise, and I still have to spend two hours manually digging through pull requests to figure out who or what caused the bottleneck."

This perfectly encapsulates the "Decision Gap." In the rush to build internal BI tools or wrap standard LLMs around company APIs, engineering teams are succeeding at plotting metrics, but failing entirely at generating context.

Showing that a metric went up or down isn’t intelligence; it’s an alarm bell. And a dashboard full of alarm bells without a fire escape plan is just a recipe for alert fatigue.

Here is why your internal AI tool is likely generating noise instead of value, and how Keypup’s NLP Analytics and Recommendation platform bridges the gap by acting as an active SDLC consultant.

📉 The Problem: Internal Tools Lack "Domain-Specific Reasoning"

Let’s look at another common question from r/devops:

Reddit (r/devops)

"How do you guys actually use cycle time metrics? Our internal tool just shows a scatterplot. When cycle time spikes, is it because requirements were unclear? Because a senior dev was on PTO? Because the PR was too large? The dashboard has no idea."

When you build a DIY analytics solution, you are essentially asking a generic system to plot X against Y. If you use a basic AI agent, it will read that data and say, "Cycle time has increased by 15%."

But generic AI models lack SDLC Domain Reasoning. They don't inherently understand the physics of software delivery. They don't know that an increase in Change Failure Rate might be directly correlated to a drop in Review Participation three days prior.

This is where the "Make" approach fails. You can build a dashboard, but building an automated, prescriptive engine requires a deeply specialized intelligence layer.

🧠 The Keypup Solution: AI SDLC Diagnosis & The Improvement Loop

Keypup isn't just an analytics dashboard—it is an NLP Analytics and Recommendation Platform built specifically for the Software Development Lifecycle.

Instead of just presenting a chart, Keypup utilizes AI SDLC Diagnosis. When a metric drifts out of bounds, Keypup narrates the story of your SDLC in plain English, identifying hidden cross-tool correlations between Jira and GitHub.

Furthermore, instead of leaving you hanging, it initiates an Improvement Loop—instantly spawning specific tracking metrics to help you monitor the success of its recommended fixes.

🛠️ Stop Guessing, Start Prompting: Concrete Examples

To illustrate the profound difference between a static internal dashboard and a contextual NLP platform, here are four concrete prompts you can run directly in Keypup to shift from monitoring to diagnosing.

Prompt 1: The Root Cause Analysis

When your DIY dashboard shows a spike in delivery time, you usually have to launch an investigation. With Keypup, you just ask the AI for the answer.

Your Prompt: "Analyze our Lead Time for Changes over the last 12 months and identify spikes? Analyze PRs merged against Jira tickets to find their root cause."

Cycle Times spike analysis and root causes by Keypup

Analysis from Keypup AI

"The correlation between Git activity and Jira tickets reveals the following root causes for lead time spikes:

Backlog Sanitization & Large Features: In May 2022, several items like [DP-41] Expand formula operators showed lead times exceeding 160 hours (6.6 days). These were high-complexity tasks (over 5,000 lines changed) that naturally extended the review and testing phases.
Release Bundling: The data shows a pattern where "Release" PRs (e.g., Release: Production in May 2022) often have lead times exceeding 100-200 hours. This indicates that code often sits in UAT or staging for several days before being officially merged into production.
Outliers & Maintenance: A few extreme outliers, such as a Github Connector fix merged in May 2022 with 4,801 hours of lead time, suggest long-running experimental branches or automated PRs that were left unattended for extended periods."

Prompt 2: The Quality Correlation Insight

Instead of visually comparing two separate charts on a BI dashboard and guessing if there is a relationship, Keypup finds the correlation for you.

Your Prompt: "What is the correlation between our Change Failure Rate and the number of PRs merged without a secondary reviewer for the period?"

Correlation between Change Failure Rate and reviewers per PRs by Keypup

Analysis from Keypup AI

📈 Quality Trends

Correlation: Data shows low direct correlation between merging with fewer than two reviewers and failure rates. This indicates that automated testing and team seniority are effectively mitigating risks.
Record Performance: May 2023 achieved a near-record low 0.9% CFR despite having the highest volume of single-reviewer merges (111 PRs).

⚠️ Risk Observations

April 2023 Volatility: A significant spike to 8.3% CFR occurred during a month with moderate reviewer volume, suggesting failures were driven by feature complexity rather than lack of oversight.
Latent Risk: The baseline of ~80 PRs/month merged with < 2 reviewers remains a potential knowledge-silo risk.

💡 Recommendations

Complexity-Based Policy: Instead of a blanket multi-reviewer rule, trigger a mandatory second review specifically for PRs exceeding a 250 lines-of-code threshold.
Retrospective: Conduct a deep dive into the April 2023 failures to identify if specific projects or release types were responsible for the quality leaks.

Prompt 3: The Contextual Cycle Time Dashboard

Instead of a generic scatterplot, ask Keypup to build a dashboard that actively monitors the causes of slow cycle times.

Your Prompt: "Create a Cycle Time diagnosis dashboard for the backend team. Overlay PR size with Time to First Review, and include a widget highlighting our top 3 longest-running Jira tickets so we can see if unclear requirements are causing coding delays."

Cycle Time diagnosis dashboard by Keypup

Analysis from Keypup AI

Key Insights

Coding Phase is the Primary Bottleneck: The average cycle time is 334 hours (~14 days), but a staggering 96% (322 hours) of that time is spent in the Coding phase (before a review is requested). In contrast, reviews and merges are handled relatively quickly once triggered.
Extreme Pull Request Sizes: The historical average PR size is 6,553 lines of code (LOC), with recent weekly spikes exceeding 10,000 LOC. This far exceeds industry standards (250–400 LOC) and is the likely root cause of delivery delays.
Aging Backlog: There is significant "rot" in the backlog, with top tickets like DP-1044 and DP-1049 remaining open for over 330 days without transitioning out of the "To Do" or "Backlog" states.

Bottlenecks and Problem Areas

PR Size vs. Responsiveness Correlation: The data shows a clear breakdown in collaboration as PR size increases. While PRs under 100 LOC are reviewed within ~24 hours, wait times spike to 847 hours for PRs in the 300 LOC range. Massive PRs are effectively "stalling" the review pipeline.
High "Idle Time" for Small PRs: Even for the smallest PRs (0 LOC/metadata changes), the wait for a first review is 56 hours. This suggests that while large PRs are the main problem, there is also a systemic delay in how the team monitors and picks up new review requests.

Recommendations

Decompose Large Tasks: The high coding time and massive PR sizes suggest that Jira issues are being scoped too broadly. Adopt a "Small PR" culture by breaking features into smaller, atomic units of work that can be reviewed and merged independently.
Implement PR Size Guards: Consider adding automated warnings or CI checks for PRs exceeding 500 lines of code to encourage developers to split their work earlier.
Backlog Sanitization: Conduct a dedicated grooming session to address the oldest tickets (300+ days). If these items are no longer relevant, they should be closed to reduce cognitive load on the team.

Priority Actions

Enforce a 400 LOC target for all new Backend PRs to improve review responsiveness.
Investigate the 56-hour delay for small PRs to see if automated notifications (e.g., Slack alerts) can speed up the "Initial Review" handoff.
Refine or Close the 5 oldest tickets identified in the "Longest-Running Jira Tickets" report to improve team focus list.

Prompt 4: The Improvement Loop Dashboard

Once you identify a problem, Keypup helps you track the solution.

Your Prompt: "Generate an Improvement Loop dashboard for Sprint 44. Track our new WIP (Work in Progress) limits, show any idle PRs older than 48 hours, and give me a summary of developers with imbalanced review workloads so we can reassign them."

Analysis from Keypup AI

🔑 Key Insights

High Work-In-Progress (WIP): You currently have 11 open PRs, which is more than double your optimal target of 5. This high WIP is likely causing significant context switching and contributing to the slow overall delivery speed.
Extended Cycle Time: The average cycle time for a PR is 214 hours (~8.9 days). This is quite high for an agile team and indicates that work is spending too much time "in the system" before reaching production.
Coding Phase is the Main Driver: The Coding time (160.8 hours) accounts for roughly 75% of the total cycle. This suggests that either PRs are becoming too large and complex, or developers are frequently interrupted while trying to finish their initial implementation.

⚠️ Bottlenecks and Problem Areas

Review Workload Imbalance: There is a severe bottleneck in your peer review process. John Foo is currently assigned to 9 open reviews, while the rest of the team averages only 2. This concentration of responsibility creates a "single point of failure"—if John is busy or away, nearly the entire team's throughput will stall.
Backlog Stagnation: The Idle PRs (> 48h) list shows 38 items that haven't been updated in over two days. While many are Dependabot updates, critical tasks like the "React 19 upgrade" and "Support project category" are also stalling, indicating that the team is starting new work instead of finishing existing PRs.
Merge Delays: Once approved, PRs take an average of 22 hours to be merged. While not the primary bottleneck, this suggests that the "last mile" of delivery (final checks or deployment) could be more streamlined.

💡 Recommendations

Enforce WIP Limits: Stop starting new features until the current WIP is reduced. Focus the team on clearing the Idle PRs first.
Redistribute Reviews: Immediately reassign some of John Foo's 9 pending reviews to other team members (like tomazernour or jbailleul) to unblock the flow.
Shrink PR Sizes: The high coding time (6.7 days) is a classic symptom of large PRs. Encourage the team to break tasks into smaller, more manageable units that can be implemented and reviewed within 24–48 hours.
Automate Dependency Management: With so many idle Dependabot PRs, consider implementing an automated "auto-merge" policy for minor dependency updates that pass all status checks.

🚀 Priority Actions

Unblock Reviews: Reassign 4–5 of John Foo's pending reviews to other team members today.
"Finish over Start": Dedicate the next 24 hours to closing or merging the 38 idle PRs before anyone picks up a new ticket.
Audit Coding Time: Review the last 3 PRs that took over 150 hours in the coding phase to identify if the specs were unclear or if the technical scope was too broad.

🚀 The Verdict: Dashboards Belong in the Past

Building an internal tool to extract data from Git and Jira APIs is technically possible. But the era of the static dashboard is over.

Tech leaders don't need more charts to look at; they need answers. They need a system that understands the nuanced, messy reality of software engineering and provides prescriptive, plain-language recommendations.

With Keypup’s NLP Analytics platform, you aren’t just buying a dashboard—you are hiring an AI engineering analyst that never sleeps, natively understands your toolchain, and tells you exactly how to optimize your SDLC.

Stop staring at spikes on a graph.Click here to connect your GitHub and Jira environments to Keypup’s AI Assistant, and let our NLP engine diagnose your SDLC today.