Station Pipeline

The Station Pipeline panel displays a left-to-right flow visualization of your SDLC stations, showing work-in-progress (WIP), throughput, cycle time, and yield for each stage. It is the primary view for identifying bottlenecks and understanding where work is getting stuck.

The Six Stations

A standard SDLC in Rensei flows through six stations:

Research - Problem analysis and requirements definition (agent-driven or manual)
Development - Implementation and code writing
Security - Security review and vulnerability assessment
QA - Testing and quality assurance
Acceptance - Business logic validation and approval
Deploy - Release to production

Each station is represented as a card in the pipeline. Work items flow left-to-right, and the metrics show the health of each stage.

Per-Station Metrics

WIP Count

The number of items currently in progress in that station (displayed in a badge if > 0).

Why it matters: High WIP indicates a bottleneck. In a healthy flow, WIP should decrease as items move downstream (funnel shape). High WIP in a middle station suggests either slow processing or blocked items.

Healthy ranges:

Research: 1-3 items (often a human decision point)
Development: 2-5 items (depends on team size)
Security: 1-2 items (typically fast)
QA: 2-4 items (depends on test coverage)
Acceptance: 1-2 items (approval gate, usually quick)
Deploy: 0-1 items (should be fast)

Throughput

Items completed per day in that station.

Why it matters: Throughput measures the rate at which work flows through each stage. Uneven throughput across stations indicates bottlenecks.

Interpretation:

Consistent across all stations → healthy flow; work is moving evenly
Dev throughput >> QA throughput → QA is the bottleneck
Research throughput >> all others → high-priority work, but downstream capacity may be constrained

Cycle Time

The median time an item spends in that station (from entry to exit).

Why it matters: Long cycle time in a station identifies where work is getting delayed. Combined with yield, it shows the quality/speed tradeoff.

Interpretation:

Research: 2-4h → normal deliberation
Development: 4-8h → normal coding time
Security: 1-2h → fast review
QA: 4-12h → depends on test coverage
Acceptance: 1-2h → quick approval
Deploy: <30m → should be automated

If any station is significantly higher, it may be a bottleneck.

Yield

The percentage of items passing first time (no rework, no return to development).

Why it matters: Yield measures quality at each stage. Low yield in a stage indicates:

QA: many defects escaping development
Security: many vulnerabilities found
Acceptance: requirements misalignment
Development: skill or template issues

Color coding:

🟢 Green (≥90%) - excellent quality
🟡 Yellow (70-89%) - acceptable; some rework
🔴 Red (<70%) - quality alert; investigate

Reading the Pipeline

A healthy pipeline visualization shows:

Decreasing WIP left-to-right (funnel shape)
Consistent throughput across stations (~same number per day)
Short cycle times (items move quickly)
High yield (≥90%) at most stations
No red-flagged stations (all green or yellow)

Example: QA Bottleneck

research     dev        security     qa         acceptance   deploy
[1 WIP]      [3 WIP]    [1 WIP]      [8 WIP]    [0 WIP]      [0 WIP]
throughput:2  throughput:3 throughput:2  throughput:0.5  throughput:2  throughput:2
cycle:3h      cycle:5h     cycle:1h       cycle:16h       cycle:1h      cycle:15m
yield:95%     yield:92%    yield:98%      yield:78%       yield:95%     yield:99%

This shows QA is slow (16h cycle time) and has low yield (78%), while WIP backs up (8 items). Recommendations:

Increase QA capacity (add more testers or increase parallelism)
Review QA templates or agent configuration
Prioritize defect prevention in development

Station Customization

The six default stations (research → development → security → qa → acceptance → deploy) are standard, but can be customized per organization via the SDLC template:

Rename stations - e.g., "Review" instead of "Security"
Add/remove stations - e.g., add "Documentation" after Development
Reorder stations - e.g., Security before QA

Station names and colors are configurable in the SDLC template YAML.

Time Windows

All station metrics aggregate over the selected time window (7d, 30d, 90d). Click the time-range selector to update. Station Pipeline metrics include:

WIP (point-in-time, independent of window)
Throughput (items completed in window)
Cycle time (median of items completed in window)
Yield (completion rate for items in window)

Data Freshness

Station metrics are updated hourly by the factory aggregation job. WIP counts are nearly real-time (refreshed on each event); cycle time and yield have a ~1-hour lag.

API Access

Fetch Station Pipeline metrics programmatically:

curl -H "Authorization: Bearer $RENSEI_API_KEY" \
  "https://app.rensei.ai/api/factory/metrics?metricType=station&timeRange=30d"

Response:

{
  "metrics": [
    {
      "station": "research",
      "wipCount": 1,
      "throughput": 2,
      "cycleTimeMs": 10800000,
      "yield": 95.0
    },
    {
      "station": "development",
      "wipCount": 3,
      "throughput": 3,
      "cycleTimeMs": 18000000,
      "yield": 92.0
    },
    ...
  ]
}

See Metrics API for full details.

Troubleshooting

High WIP in Research

Are requirements being written too slowly?
Should some work be filtered out (low-priority items)?
Is the agent asking for too much context before implementation?

High WIP in Development

Are developers experiencing blockers?
Is the codebase or dependencies causing delays?
Should work be parallelized differently?

High WIP in QA

Are test cases comprehensive but slow to execute?
Should QA be parallelized?
Are defects from dev causing rework?

Low Yield in QA

Are tests catching issues that slipped from dev?
Are requirements misaligned between dev and QA?
Should dev shift left (test earlier)?

Next Steps

For per-station cost attribution, see Cost Breakdown
To understand why yield is low, check Rework & Escalation
To configure station-level SLAs, see SDLC Templates

On this page