# Technical Project Manager — Glossary of Essential Terms

---

## Agile & Scrum

**Agile** — A project management philosophy based on iterative development, collaboration, and adaptability. Instead of planning everything upfront (waterfall), you deliver work in small increments and adjust based on feedback.

**Scrum** — The most popular Agile framework. Work is done in short cycles called sprints, with defined roles (Product Owner, Scrum Master, Development Team) and ceremonies.

**Kanban** — Another Agile framework focused on visualizing work, limiting work-in-progress (WIP), and continuous flow rather than fixed sprints. Common board columns: To Do → In Progress → In Review → Done.

**Sprint** — A fixed time period (usually 2 weeks) during which the team commits to completing a set of work. At the end, you demo what was built and plan the next sprint.

**Sprint Planning** — A meeting at the start of each sprint where the team selects items from the backlog, discusses how to implement them, and commits to what they'll deliver.

**Daily Standup (Daily Scrum)** — A short daily meeting (15 min max) where each team member answers: What did I do yesterday? What will I do today? Any blockers?

**Sprint Review (Demo)** — A meeting at the end of a sprint where the team demonstrates completed work to stakeholders and gathers feedback.

**Sprint Retrospective (Retro)** — A meeting after the sprint review where the team reflects on what went well, what didn't, and what to improve next sprint. Formats include Start/Stop/Continue, Liked/Learned/Lacked, and Sailboat.

**Velocity** — The average amount of work (measured in story points) a team completes per sprint. Used for forecasting future sprints, not as a performance metric.

**Burndown Chart** — A graph showing remaining work vs. time in a sprint. The ideal line goes from total points down to zero. If the actual line is above the ideal, the team is behind.

**Burnup Chart** — Similar to burndown but shows work completed vs. total scope. Better for visualizing scope changes over time.

**Backlog** — The prioritized list of all work to be done. The Product Owner maintains the product backlog; the sprint backlog is what's selected for the current sprint.

**Backlog Grooming (Refinement)** — A recurring session where the team reviews upcoming backlog items, adds detail, estimates effort, and breaks down large items. Usually done mid-sprint to prepare for the next sprint planning.

**Product Owner (PO)** — The person responsible for defining what gets built and in what order. Owns the product backlog and represents stakeholder interests.

**Scrum Master** — The person who facilitates Scrum ceremonies, removes blockers, and coaches the team on Agile practices. Not a manager — more of a servant leader.

**Story Points** — A relative measure of effort/complexity used to estimate work. Commonly uses the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21). A "5" is roughly twice as complex as a "3." They are not hours.

**Planning Poker** — An estimation technique where each team member privately selects a story point card, then all reveal simultaneously to avoid anchoring bias. Differences are discussed until consensus.

**T-shirt Sizing** — A quick estimation method using sizes (XS, S, M, L, XL) to roughly categorize effort before doing more precise estimation.

**Definition of Done (DoD)** — The agreed-upon criteria that must be met before any work item is considered complete. Example: code reviewed, tests passing, documentation updated, deployed to staging.

**Definition of Ready (DoR)** — Criteria a backlog item must meet before it can be pulled into a sprint. Example: acceptance criteria written, dependencies identified, designs approved.

**WIP Limit (Work in Progress)** — A cap on how many items can be in a given stage at once. Prevents multitasking and bottlenecks. Core concept in Kanban.

---

## Work Items & Hierarchy

**Epic** — A large body of work that can be broken down into smaller pieces. Usually spans multiple sprints. Example: "User Authentication System."

**User Story** — A short, simple description of a feature from the user's perspective. Format: "As a [type of user], I want [action] so that [benefit]."

**Task** — A specific, actionable piece of work needed to complete a story. Example: "Create database schema for user profiles."

**Subtask** — A smaller division of a task. Used when a task is still too large for one person in one day.

**Bug** — A defect or error in existing functionality that needs to be fixed.

**Spike** — A time-boxed research task to answer a question or reduce uncertainty. Example: "Investigate whether we can use WebSockets for real-time notifications (2 days max)."

**Tech Debt (Technical Debt)** — Shortcuts or suboptimal code that was acceptable at the time but needs to be cleaned up later. Accumulates like financial debt — the longer you wait, the more it costs.

**Acceptance Criteria (AC)** — Specific conditions that must be true for a story to be considered complete. Written from the user's perspective. Example: "Given I am logged in, when I click 'Export,' then a CSV file downloads within 5 seconds."

---

## Planning & Prioritization

**Roadmap** — A high-level visual plan showing what the team intends to build over a longer timeframe (quarter, half, year). Communicates direction to stakeholders without committing to exact dates.

**Milestone** — A significant checkpoint or deliverable in a project timeline. Example: "Beta launch," "Security audit complete."

**MoSCoW Prioritization** — A framework for prioritizing requirements: **M**ust have, **S**hould have, **C**ould have, **W**on't have (this time).

**RICE Scoring** — A prioritization framework: **R**each × **I**mpact × **C**onfidence ÷ **E**ffort = Priority Score.

**OKRs (Objectives and Key Results)** — A goal-setting framework. Objective = what you want to achieve (qualitative). Key Results = how you measure progress (quantitative). Example: Objective: "Improve platform reliability." KR1: "Reduce downtime to < 30 min/month." KR2: "Achieve 99.9% uptime."

**KPI (Key Performance Indicator)** — A measurable value that shows how effectively a team or project is achieving its objectives. Example: deployment frequency, customer churn rate, sprint velocity.

**Gantt Chart** — A horizontal bar chart showing tasks plotted against a timeline, with dependencies and milestones. Best for communicating timelines to stakeholders.

**Critical Path** — The longest sequence of dependent tasks in a project. Determines the minimum project duration. Any delay on the critical path delays the whole project.

**Dependencies** — Relationships between tasks where one must be completed (or started) before another can proceed. Types: Finish-to-Start (most common), Start-to-Start, Finish-to-Finish, Start-to-Finish.

**Scope Creep** — When new features or requirements are added without adjusting timeline, budget, or resources. A TPM's job is to identify and manage this.

**RAG Status (Red/Amber/Green)** — A simple traffic-light system for reporting project health. Red = blocked/at risk. Amber = issues but manageable. Green = on track.

**RACI Matrix** — A chart that maps tasks to roles: **R**esponsible (who does it), **A**ccountable (who owns it), **C**onsulted (who gives input), **I**nformed (who needs updates).

---

## Software Development & Engineering

**SDLC (Software Development Life Cycle)** — The process of planning, building, testing, deploying, and maintaining software. Common models: Waterfall, Agile, V-Model.

**CI/CD (Continuous Integration / Continuous Deployment)** — CI: Developers merge code frequently, and automated tests run on every merge. CD: Code that passes tests is automatically deployed to production (or staging). Tools: GitHub Actions, Jenkins, CircleCI.

**PR (Pull Request) / MR (Merge Request)** — A request to merge code changes into the main codebase. Other developers review the code before approving. TPMs track PR throughput as a health metric.

**Code Review** — The process of examining someone else's code for bugs, style, and quality before it's merged. TPMs don't review code but should understand the process and its impact on timelines.

**QA (Quality Assurance)** — The process of testing software to find bugs before release. Includes manual testing, automated testing, regression testing, and user acceptance testing (UAT).

**Staging Environment** — A replica of the production environment where code is tested before going live. Changes go: Dev → Staging → Production.

**Production (Prod)** — The live environment that real users interact with. "Pushing to prod" means deploying code to the live system.

**Deployment** — The process of releasing new code or updates to an environment (staging or production).

**Rollback** — Reverting to a previous version of the software after a failed deployment or critical bug.

**Feature Flag (Feature Toggle)** — A mechanism to enable or disable features without deploying new code. Allows gradual rollouts ("release to 10% of users first") and quick kill switches.

**API (Application Programming Interface)** — A set of rules that allows different software systems to communicate. Example: Your app calls Stripe's API to process payments. As a TPM, you'll coordinate API design and integration timelines.

**Microservices** — An architecture where an application is built as a collection of small, independent services (auth service, payment service, notification service) rather than one large codebase (monolith).

**Monolith** — A single, unified application where all components are interconnected. Simpler to start with but harder to scale and maintain over time.

**Technical Spec (Tech Spec)** — A document written by engineers describing how a feature will be implemented technically. Covers architecture, data models, APIs, and edge cases.

**PRD (Product Requirements Document)** — A document (often written by PMs/TPMs) describing what needs to be built and why, without specifying how. Includes user stories, acceptance criteria, success metrics, and scope.

**RFC (Request for Comments)** — A proposal document shared with the team for feedback before implementation. Common for architectural decisions or process changes.

**ADR (Architecture Decision Record)** — A short document capturing an important architectural decision, the context, and the reasoning. Helps future team members understand why things were built a certain way.

---

## Incident Management & Reliability

**Incident** — An unplanned event that disrupts or degrades a service. Examples: site goes down, payments fail, data loss.

**Severity Levels (Sev1–Sev4)** — Classification of incident impact. Sev1/P1 = critical (entire service down, data breach). Sev4/P4 = minor (cosmetic issue, workaround available).

**On-call** — A rotation where engineers are available 24/7 to respond to incidents. Managed through tools like PagerDuty or Opsgenie.

**SLA (Service Level Agreement)** — A formal commitment to customers about service quality. Example: "99.9% uptime" or "Support response within 4 hours." Breaking an SLA can have financial penalties.

**SLO (Service Level Objective)** — An internal target for service quality, usually stricter than the SLA. Example: internal SLO of 99.95% uptime vs. customer-facing SLA of 99.9%.

**SLI (Service Level Indicator)** — The actual metric being measured. Example: the percentage of successful requests over total requests.

**Uptime** — The percentage of time a service is operational. "Five nines" (99.999%) means only ~5 minutes of downtime per year.

**Postmortem (Post-Incident Review)** — A blameless analysis conducted after an incident to understand what happened, why, and how to prevent it. Documents timeline, root cause, impact, and action items.

**Root Cause Analysis (RCA)** — The process of identifying the fundamental reason an incident occurred, not just the symptoms. Techniques include "5 Whys" and Fishbone diagrams.

**Runbook** — A set of step-by-step instructions for handling common operational tasks or incidents. Example: "How to restart the payment service" or "Steps when database CPU exceeds 90%."

**MTTR (Mean Time to Resolve)** — The average time from when an incident starts to when it's fully resolved. A key reliability metric.

**MTTD (Mean Time to Detect)** — The average time from when an incident begins to when the team becomes aware of it.

---

## Communication & Stakeholder Management

**Stakeholder** — Anyone who has an interest in or is affected by the project. Includes executives, product managers, engineers, designers, customers, and partner teams.

**Standup Update** — A concise status format. Common structure: Progress (what's done), Plans (what's next), Problems (blockers or risks).

**Blocker** — Anything preventing a team member or the project from moving forward. A TPM's primary job is to identify and remove blockers.

**Escalation** — Raising an issue to a higher authority or decision-maker when it can't be resolved at the current level. Example: escalating a resource conflict to a VP.

**ETA (Estimated Time of Arrival)** — When something is expected to be completed. TPMs are constantly asked for ETAs and must balance accuracy with confidence.

**Sync (Synchronous)** — Real-time communication. Meetings, video calls, live Slack conversations.

**Async (Asynchronous)** — Communication that doesn't require everyone to be present simultaneously. Emails, recorded Loom videos, Slack threads, documentation. Essential for distributed teams.

**Decision Log** — A record of key decisions made during a project, including context, alternatives considered, and rationale. Prevents revisiting the same debates.

**Status Report** — A regular update (weekly or biweekly) to stakeholders covering progress, risks, blockers, and upcoming milestones.

**One-pager** — A concise, single-page document summarizing a project proposal, feature request, or decision. Usually includes problem statement, proposed solution, success metrics, timeline, and risks.

---

## Risk Management

**Risk** — A potential event that could negatively impact the project. Characterized by probability (likelihood) and impact (severity).

**Risk Register** — A document tracking all identified risks, their probability, impact, mitigation strategies, and owners.

**Mitigation** — Actions taken to reduce the probability or impact of a risk before it occurs.

**Contingency Plan** — A predetermined response to be executed if a risk materializes. The "Plan B."

**Single Point of Failure (SPOF)** — A component or person whose failure would bring down the entire system or project. TPMs work to eliminate SPOFs.

**Bus Factor** — The number of people who would need to be "hit by a bus" (leave the project) before the project stalls. A bus factor of 1 is dangerous. Knowledge sharing and documentation increase the bus factor.

---

## Metrics & Delivery

**Lead Time** — The total time from when a request is made to when it's delivered. Includes waiting time + work time.

**Cycle Time** — The time from when work actually begins on an item to when it's completed. Shorter than lead time.

**Throughput** — The number of items completed in a given time period. Example: "The team ships 12 stories per sprint."

**DORA Metrics** — Four key metrics from the DevOps Research and Assessment team that measure software delivery performance: Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore Service.

**Ship / Ship It** — To release or deploy. "When are we shipping this feature?" means "When is it going live?"

**MVP (Minimum Viable Product)** — The smallest version of a product that delivers enough value to test with real users and gather feedback. Not a prototype — it must actually work.

**POC (Proof of Concept)** — A small experiment to test whether an idea or technology is feasible before committing to full development.

**Go/No-Go** — A decision point where stakeholders decide whether to proceed with a launch or milestone based on readiness criteria.

**Launch Criteria** — The checklist of requirements that must be met before a product or feature can go live. Example: load testing passed, documentation complete, monitoring dashboards set up, rollback plan documented.

---

## Meetings & Ceremonies

**Ceremony** — In Scrum, the recurring meetings that structure the sprint: Sprint Planning, Daily Standup, Sprint Review, and Sprint Retrospective.

**Kickoff** — The initial meeting for a new project where the team aligns on goals, scope, timeline, roles, and expectations.

**Working Session** — A focused meeting where participants actively collaborate to produce an output (design review, architecture discussion, writing a spec). Not a status update — actual work gets done.

**Brown Bag / Lunch & Learn** — An informal knowledge-sharing session where someone presents a topic to the team. Great for spreading technical knowledge across a team.

**All-Hands** — A meeting with the entire organization or department, usually led by leadership to share updates, strategy, and Q&A.

**1:1 (One-on-One)** — A recurring private meeting between a manager and their direct report, or between a TPM and a key stakeholder, to discuss progress, concerns, and career development.

**Office Hours** — Designated time when a TPM (or any team member) is available for ad-hoc questions. Reduces interruptions during focus time while staying accessible.

---

## Common Acronyms Quick Reference

| Acronym | Meaning |
|---------|---------|
| PM | Project Manager or Product Manager (context matters) |
| TPM | Technical Project Manager or Technical Program Manager |
| PO | Product Owner |
| SM | Scrum Master |
| EM | Engineering Manager |
| IC | Individual Contributor |
| JIRA | Originally "Japan's Industrial Robot Association" — now just a brand name |
| EOD | End of Day |
| ETA | Estimated Time of Arrival |
| TBD | To Be Determined |
| WIP | Work in Progress |
| LGTM | Looks Good To Me (code review approval) |
| TL;DR | Too Long; Didn't Read (a summary) |
| FYI | For Your Information |
| AFAIK | As Far As I Know |
| IMO / IMHO | In My (Humble) Opinion |
| OOO | Out of Office |
| PTO | Paid Time Off |
| AFK | Away From Keyboard |
| SoW | Statement of Work |
| NDA | Non-Disclosure Agreement |
| UAT | User Acceptance Testing |
| UX | User Experience |
| UI | User Interface |

---

*Last updated: March 2026 — Created as a study reference for Technical Project Management roles.*