Phase 4:
Intelligence
Historical velocity, capacity planning, AI-driven ETAs, and sprint visualization -- moving from static estimates to dynamic predictions.
The Problem
Deterministic ETAs don't account for reality. We need to learn from history.
How ETAs Work Today
Based on a single estimate
40 hours / 8 hours per day = 5 days
Ignores reality
No queue position, no team load, no history
Never updates
Set once at creation, wrong by day 3
Static bar. Never moves. Always wrong.
Based on actual velocity
Team completes 4.2 items/week (8-week avg)
Models team capacity
Glen: 60% DH, 40% MF. Adjusts in real time.
Updates continuously
Queue changes, capacity shifts, scope grows
Live cursor. Recalculates on every change.
Team Velocity Tracking
Track items completed per week over a rolling window. See who delivers what and how fast.
Weekly Completions (Rolling 8-Week Window)
Items moved to terminal stage per week
Glen
26 items / 8 wk
Developer B
14 items / 8 wk
Team Total
39 items / 8 wk
Developer Capacity Model
Model weekly hours, project allocations, and utilization across the team.
Developer Allocation Map
Weekly hours allocated per project
Utilization formula: utilization = allocated_hours / capacity_hours * 100. A developer at 100% utilization has no slack for unplanned work, context switching, or meetings. The system flags anything above 90% as a capacity risk.
Dynamic ETA Engine
What-if scenarios: add items, lose a developer, change priorities -- see how ETAs shift.
What-If Scenario Modeler
Current state: 15 items, 3 developers, 4.2 items/week velocity
Queue Position
Each item gets a projected start date based on its position in the backlog and team throughput.
Capacity Weighting
A developer at 60% allocation on DH contributes 0.6x to DH velocity. The model accounts for split attention.
Continuous Recalc
Every time a work item changes stage, the engine recalculates all downstream ETAs in the queue.
Sprint / Burndown Visualization
Track planned vs actual completion. Make scope changes visible, not hidden.
Sprint Burndown Chart
Planned vs actual completion over a 2-week sprint
Planned Work
40 pts
Sprint commitment
Scope Change
+4 pts
Added mid-sprint (Day 5)
Remaining
10 pts
Carried to next sprint
Key insight: The burndown tracks three lines: the ideal (linear path to zero), the actual (what really happened), and total scope (which jumps when items are added mid-sprint). The gap between ideal and actual reveals patterns -- late starts, blocked items, estimation drift. The scope line makes mid-sprint changes visible instead of hidden.
What Gets Built
New CMT, Apex service, LWC dashboard, and integration with the existing ETA service.
Component Architecture
deliveryVelocityDashboard
Charts + What-If
deliveryClientDashboard
Enhanced with ETAs
deliveryHubBoard
Inline ETA badges
DeliveryVelocityService
Velocity + Capacity
WorkItemETAService
Enhanced ETAs
WorkflowConfigService
CMT Config
DeveloperCapacity__mdt
CMT
WorkItem__c
Stage history
WorkLog__c
Hours logged
ActivityLog__c
Event stream
DeveloperCapacity__mdt
Stores per-developer capacity (hours/week), project allocation percentages, and availability windows. Queryable in Apex, deployable via git.
DeveloperNameWeeklyCapacityHrsAllocations (JSON)EffectiveDateIsActiveDeliveryVelocityService.cls
Calculates rolling velocity (items/week, hours/week), projects ETAs based on queue position and capacity, runs utilization reports.
getTeamVelocity(workflowType, weeks)getProjectedETAs(entityId)getDeveloperUtilization()getWhatIfProjection(params)deliveryVelocityDashboard
Visual dashboard showing velocity charts, capacity bars, burndown, and what-if projections. Embeddable on home page and record pages.
@wire getTeamVelocity@wire getDeveloperUtilizationinteractive scenario selectorresponsive chart renderingETA Service (enhanced)
The existing WorkItemETAService gets parameterized to accept velocity data instead of using only static estimates. Falls back to estimate-based ETAs when velocity data is insufficient.
estimateBasedETA (existing)velocityBasedETA (new)hybridETA (blended)confidenceScore (0-100)Design Choices
Why DeveloperCapacity is CMT, why items-per-week, and why what-if is client-side.
Why Custom Metadata (DeveloperCapacity__mdt) for developer capacity
Capacity is configuration, not transactional data. CMT deploys with the package via git, survives org refreshes and sandbox copies, and is queryable in Apex without DML. It is admin-configurable in Setup without code. This is consistent with the existing CMT pattern used throughout Delivery Hub: WorkflowType__mdt, WorkflowStage__mdt, and WorkflowPersonaView__mdt all follow the same approach. Admins set capacity once and update it rarely -- the same update cadence as workflow stages.
Why items-per-week as the velocity metric (not story points or hours)
Items completed per week is the simplest universal metric. It requires no estimation discipline (story points), no time tracking (hours), and no subjective weighting. Every team completes items. Not every team estimates consistently, and not every team logs hours. Items/week is observable from stage transitions alone -- data that Delivery Hub already captures via Ghost Recorder. The metric also makes what-if analysis intuitive: 'we have 15 items and complete 4.2/week, so ~3.6 weeks.'
Why what-if analysis is client-side only (no Apex call)
The what-if scenario modeler takes the current velocity, queue size, and developer count, then recalculates projected dates in JavaScript. No Apex call is needed because the formula is simple arithmetic: queue / velocity = weeks. This gives instant feedback when users toggle scenarios -- no spinner, no network latency, no governor limits. The base data (velocity, queue size) is fetched once via @wire; all scenario permutations happen in the browser.
Architecture: 1 Apex service + 1 LWC dashboard + 1 CMT for config
The entire Phase 4 feature set is three components. DeliveryVelocityService.cls handles all server-side calculations (rolling velocity, projected ETAs, utilization). deliveryVelocityDashboard LWC renders charts, capacity bars, and the what-if tool. DeveloperCapacity__mdt stores the config. This minimal surface area means fewer tests, fewer deployment risks, and fewer things to maintain. The ETA integration enhances the existing WorkItemETAService rather than replacing it.
Why not a field on User for developer capacity
The User object is shared across all apps in the org. Adding delivery-specific fields (WeeklyCapacityHrs, AllocationPct) to User pollutes the standard object and requires admin permissions to modify. CMT records are package-scoped, deployable, and won't collide with other apps or customizations in the org.
Why allocation percentages instead of fixed hour assignments
Real teams split time across projects. A developer at 60% on Delivery Hub and 40% on Client Project A has different effective capacity for each. The percentage model captures this reality and adjusts automatically when total capacity changes (e.g., 32h/week instead of 40h/week for a part-time developer). The math stays simple: effective_hours = capacity * allocation_pct.
Risks & Considerations
Every feature has trade-offs. Here are the ones worth thinking about now.
Garbage In, Garbage Out
highVelocity tracking requires consistent workflow usage. If the team skips stages, backdates items, or doesn't log work, the data is meaningless.
Enforce stage transitions via validation rules. Surface data quality score in dashboard.
Small Team Problem
mediumWith 1-2 developers, 8 weeks of data may show too much variance to be predictive. A single vacation or sick day swings velocity 25%.
Use longer rolling windows for small teams. Show confidence intervals, not point estimates.
Projections Are Not Commitments
mediumWhat-if projections are scenario models, not promises. Clients may interpret projected dates as deadlines. Need clear UX language.
Label all projections as 'estimated'. Use confidence bands (70%/90%). Never show to clients without admin approval.
Micromanagement Risk
highPer-developer velocity data could be misused to pressure individuals rather than improve team planning. This is an organizational problem, not a technical one.
Default to team-level views. Per-developer data behind admin toggle. Explicit 'intended use' guidance in docs.
Data Volume
lowVelocity calculations query completed items over rolling windows. In orgs with thousands of items, aggregate queries could hit governor limits.
Pre-calculate weekly snapshots in a VelocitySnapshot__c record. Query snapshots, not raw items.
Recommendation: Use intelligence features for team-level planning and client communication, not individual performance reviews. The goal is to answer "when will this get done?" and "do we have capacity for more?" -- not "who is the slowest developer?"
Open Questions for Glen
Design decisions that need your input before we start building.
What time period defines a "sprint"?
Fixed 2-week cycles, flexible periods, or no sprints at all? This affects how burndown charts are scoped and whether we need sprint planning UI.
Determines whether we build a sprint management UI or use rolling windows only.
Should velocity track items completed or hours logged?
Items/week is simpler and doesn't require hour logging. Hours/week is more granular but depends on consistent WorkLog usage.
Items = simpler, less data dependency. Hours = more accurate, higher maintenance burden.
Should the what-if tool be client-facing or admin-only?
Clients might find it valuable for planning, but it could also create expectations around projected dates that you don't want to commit to.
Client-facing requires careful UX language and confidence intervals. Admin-only is simpler.
Is burndown relevant without fixed sprints?
Classical burndown assumes a fixed scope at sprint start. In continuous flow, there's no 'sprint start' moment. Cumulative flow diagrams may be more appropriate.
Burndown = familiar to dev teams. Cumulative flow = better for continuous delivery.
What data sources matter most?
Work items (stage changes), work logs (hours), and activity logs (events) all contribute signal. Prioritizing one affects what we query and how we weight the model.
Drives the data model for VelocitySnapshot__c and determines query complexity.
About This Document
Phase 4: Intelligence is the roadmap item labeled "Future" in the architecture page. This document expands on what those intelligence features look like in practice -- velocity tracking, capacity planning, dynamic ETAs, and burndown charts. All visualizations on this page are mock data illustrating how the features would work once built. No code has been written yet for this phase.