What it is
Operation View is a panel on each iteration showing engineering delivery metrics sourced from your connected repositories: how pull requests are moving through review, how often you're deploying, and how much code changed.
How to read it
Pull requests are grouped into five buckets by age and state: closed, fresh, aging, stale, and critical — the further along, the longer a PR has sat without merging. Release metrics show deployment counts and the percentage of failed releases for the iteration. A "Lines of Code" watermark gives a rough sense of change volume. Stage timers (Sent → Seen, Seen → Approved, Approved → Merged, Merged → Deployed) show where PRs spend the most time. A separate FCT (Flow Cycle Time) figure, shown in the sprint summary rather than Operation View itself, is the average time from starting a task to completing it.
What to do about it
A growing count of aging or stale PRs is an early warning independent of sprint Momentum — code can be stuck in review even when the sprint looks healthy. Use the stage timers to find where PRs are actually stalling rather than guessing. See Spotting Delivery Bottlenecks with Operation View for combining this with sprint execution data.
Operation View's underlying data refreshes as GitHub sends webhook events for new pull requests, deployments, and commits — you don't need to manually resync a connected repository. For engineering signal at the repository level rather than the iteration level — CI success rate, security alerts — see Understanding Repository Health.