This guide is for QA and Release leaders who want earlier signals for release risk and fewer late-cycle surprises. It shows how to use Metrics → Delivery, Teams → Iterations, and gitStream (if enabled) to spot friction, stabilize releases, and reinforce low-noise PR hygiene.
TL;DR – QA & Release:
- Use Metrics → Delivery to spot review and merge friction that stalls release throughput.
- Use Teams → Iterations (Current + Completed) to see scope churn, carryover, and unplanned work that drives late risk.
- Use gitStream (if enabled) to enforce low-noise PR hygiene and safe-change patterns without slowing teams.
- If your org has configured reliability / incident signals, weave them into your release narrative.
Start here in 15 minutes
- Pick one team that regularly feeds your main release train.
- Go to Metrics → Delivery and set the window to the last 2–4 weeks.
- Note which stage is slowest: Coding, Pickup, Review, or Deploy Time.
- Open Teams → Iterations → Completed for that team and look at:
- How much work was unplanned.
- What slipped to the next iteration.
- Write down one release risk pattern (e.g., “late unplanned bugs” or “rushed PRs before release”).
- Bring that one pattern to your next release or planning meeting as a concrete topic.
Who this guide is for
You’re responsible for helping the org ship stable releases on time. This guide assumes you:
- Own or influence release readiness and quality gates.
- Partner with Engineering Managers, Tech Leads, and SRE/Infra.
- Care about predictable releases, not just pass/fail test runs.
What you likely care about
- Are PRs flowing cleanly into release windows, or getting stuck in review/merge?
- Is late unplanned work increasing release risk and creating last-minute chaos?
- Are PR sizes, review patterns, and rework contributing to instability?
- Can you connect release outcomes to concrete delivery and quality signals?
Before you begin
Make sure the following are in place:
- Git integration is connected and active.
- Teams and contributors are configured so Delivery metrics reflect real teams.
- Your release cadence (e.g., weekly, bi-weekly) is clear so you can align time windows.
- If available, reliability / incident metrics are configured and mapped to services.
- If your org uses gitStream, you know which repos / teams it currently covers.
Step 1: Baseline release flow in Metrics → Delivery
Goal: See where PRs slow down on their path into a release.
Where: Metrics → Delivery (Cycle Time, Pickup, Review, Deploy Time, PR size)
- Choose a recent release window (e.g., last 2–4 weeks) and a representative team or service.
- Review:
- Overall Cycle Time trend.
- Breakdown into Coding, Pickup, Review, Deploy Time.
- PR size distribution and review-related metrics where available.
- Highlight stages that create release risk, for example:
- Long Pickup or Review Time leading to last-minute merges.
- Spikes in Deploy Time tied to larger batches of changes.
QA lens: Treat stage-level trends as system signals, not individual performance. You’re looking for patterns that repeatedly cause late risk.
Step 2: Use Iterations to catch late risk early
Goal: Understand how planning stability affects release reliability.
Where: Teams → Iterations (Current + Completed)
2.1 – Current iteration: catch churn before it hits the release
- Open the Current iteration for key teams feeding the next release.
- Scan for:
- Unplanned work spiking mid-sprint.
- Scope churn or frequent priority changes.
- Issues without linked PRs or work that may not land before the release cut.
- Flag items that pose release risk (e.g., late critical fixes, large new scope) and align with EM/PM on tradeoffs.
2.2 – Completed iterations: learn from previous releases
- Switch to Completed and look at the last 2–3 iterations that fed recent releases.
- Review:
- Planned vs. delivered scope.
- Carryover themes—which types of work consistently slip.
- Unplanned work sources and whether they cluster near release dates.
- Turn one recurring pattern (e.g., “late bugs from service X”) into a specific improvement experiment.
Step 3: Connect releases to reliability & incidents (if configured)
Goal: Tie release decisions to real reliability impact.
If your organization has configured reliability or incident signals in LinearB, pair them with your Delivery and Iterations views:
- Look for releases or services with spikes in incidents or failure signals.
- Trace those back to:
- PR size and review patterns for the release.
- Unplanned work or rushed fixes in Iterations.
- Capture 1–2 concrete “cause → effect” stories for your release review (for example, “Oversized PRs + rushed reviews on Service A preceded two incidents in the same week”).
Step 4: Use gitStream to enforce safe, low-noise PR hygiene
Goal: Turn your release learnings into scalable guardrails.
Where: gitStream Hub (if enabled)
- Start with lightweight rules that support QA goals, such as:
- Flagging oversized PRs for extra review.
- Auto-labeling PRs by risk or area (e.g., critical services, risky directories).
- Surfacing AI review or additional checks for high-risk changes.
- Roll changes out to a small set of repos/teams first, then expand once tuned.
- Use Delivery metrics to confirm you’ve reduced risk without adding unnecessary delay.
Principle: Start with helpful guardrails, not heavy-handed gates. The goal is to improve release safety while preserving flow.
Step 5: Establish a simple release operating rhythm
Goal: Make QA & Release reviews repeatable, not ad-hoc.
Weekly / per iteration
- Review Iterations (Current) mid-sprint to confirm scope stability and rising unplanned work.
- Scan Metrics → Delivery for review/merge slowdowns on release-critical repos.
- Bring 1 focused question to EM/PM: “What’s the smallest change we can make next week to reduce this release bottleneck?”
End of sprint / post-release
- Use Iterations (Completed) to review scope delivered vs. planned and sources of unplanned work.
- Pair any post-release incidents with Delivery patterns (large PRs, rushed reviews).
- Agree on one QA or release hygiene experiment for the next cycle.
Common pitfalls
- Using Delivery metrics to judge individuals instead of system bottlenecks.
- Focusing only on test results and ignoring PR review/merge patterns that create late risk.
- Adding heavy approval steps instead of small, automatable guardrails.
- Trying to fix everything in one release instead of one focused improvement at a time.