QA & Release Management

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

1. Pick one team that regularly feeds your main release train.
2. Go to Metrics → Delivery and set the window to the last 2–4 weeks.
3. Note which stage is slowest: Coding, Pickup, Review, or Deploy Time.
4. Open Teams → Iterations → Completed for that team and look at:
   • How much work was unplanned.
   • What slipped to the next iteration.
5. Write down one release risk pattern (e.g., “late unplanned bugs” or “rushed PRs before release”).
6. 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)

1. Choose a recent release window (e.g., last 2–4 weeks) and a representative team or service.
2. Review:
   • Overall Cycle Time trend.
   • Breakdown into Coding, Pickup, Review, Deploy Time.
   • PR size distribution and review-related metrics where available.
3. 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.

---

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.

---

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.

---

Recommended next articles

• Learn about our delivery metrics
• Iterations & AI Iteration Summary
• gitStream Hub