Engineering Manager

This guide is for Engineering Managers who need a simple, reliable way to run healthier sprints and improve team flow. It focuses on the views that help you spot bottlenecks early, reduce unplanned work impact, and align on one small improvement per iteration.

---

Time Required: 6–10 minutes to orient, 15 minutes to set a sprint rhythm
Difficulty: Easy

---

TL;DR

• Use Teams → Iterations (Current) to manage live sprint risk and scope.
• Use Teams → Iterations (Completed) to understand planned vs. unplanned work and carryover.
• Use Metrics → Delivery to see where flow slows (coding, pickup, review, merge).
• Use gitStream to reduce review friction with low-noise guardrails.
• Use Developer Coaching to keep workload sustainable and reduce knowledge risk.

---

Start here in 15 minutes

1. Pick one representative team that you directly manage.
2. Open Teams → Iterations (Current):
   • Check scope vs. commitment for the current sprint.
   • Scan at-risk items (blocked, behind, large, unlinked) and capture 2 talking points for standup.
3. Open Teams → Iterations (Completed) for the last sprint:
   • Note planned vs. unplanned %, and how much work carried over.
   • If AI Iteration Summary is enabled, skim the summary and copy 1–2 suggested improvements.
4. Open Metrics → Delivery for that team:
   • Confirm which stage is slowest (Coding, Pickup, Review, Deploy Time).
   • Write down one small, testable change you will try next sprint to improve that stage.
5. Share the one change with your team and add it to your retro or sprint planning notes.

---

What you likely care about

• Are we on track for this iteration, or is risk building up quietly?
• What is causing carryover and scope instability from sprint to sprint?
• Where are PRs getting stuck, and how do we shorten that feedback loop?
• Is workload sustainable for each engineer on the team?

---

Where to spend time in LinearB

Teams → Iterations (Current)

• Use in standups and mid-sprint checks.
• Watch for:
  • Scope creep (new work added vs. committed scope).
  • Blocked or idle items that have not moved in several days.
  • Large or risky items that may not fit in the remaining time.
• Agree who will unblock each at-risk item before you leave standup.

Teams → Iterations (Completed)

• Use for retros and iteration reviews.
• Review:
  • Planned vs. unplanned work and trend over the last few sprints.
  • Carryover: what rolled and why.
  • If AI Iteration Summary is enabled, use it to frame the story and proposed actions.
• Capture 1–2 concrete improvements for the next sprint (not a long wish list).

Metrics → Delivery

• Use monthly or every few sprints to see if changes are improving flow.
• Identify the slowest stage and align the team on which one you are improving next.
• Compare similar teams to see which practices might be worth copying.

gitStream

• Use to encode simple, low-noise standards around PR size, reviewers, and risk.
• Start with:
  • Flagging oversized PRs.
  • Routing reviews to the right code owners or experts.
  • Lightweight AI review to speed up feedback, where available.

Developer Coaching

• Use to monitor individual workload and review balance.
• Watch for engineers who are consistently overloaded with PRs, incidents, or reviews.
• Use these insights to redistribute work and reduce single-point-of-failure risks.

---

Metrics to prioritize

• Cycle Time with stage breakdown, so you know where to focus improvements.
• Planned vs. unplanned work and carryover per sprint.
• PR size and review-friction patterns (slow Pickup or Review Time).
• Unlinked work signals when your teams rely on PM linking.

---

Recommended EM operating rhythm

Daily (standup)

• Open Teams → Iterations (Current) for your team.
• Scan at-risk items and confirm owners and next steps.

Mid-sprint

• Re-check scope vs. commitment and adjust if new high-priority work appears.

End of sprint

• Open Teams → Iterations (Completed) and review planned vs. unplanned, carryover, and AI summary (if enabled).
• Agree on 1–2 improvements to test next sprint.

Every few sprints

• Use Metrics → Delivery to confirm whether those improvements are moving Cycle Time and review metrics in the right direction.

---

Recommended next articles

• Team Iterations & AI Iteration Summary
• Explore LinearB's delivery metrics
• gitStream Hub