Session 08: Working with Eng — Estimation, Technical Debt, and Incident Response

Part 1: Estimation — A Problem With No Right Answer

You've learned enough of the technology — web, databases, APIs, architecture, deployment, security, performance. This final session is about something just as important: how to work effectively with the people who build those systems.

Why story points don't map to days

Ask a carpenter "how long to build this chair?" If he's never seen the design, doesn't know the wood, and doesn't know whether he has the right tools — his estimate is very likely to be wrong. That's exactly the position a dev is in when the spec is unclear.

Story points were designed to estimate relative effort — how many times harder feature A is than feature B — not to map to absolute time. But in practice, everyone asks "5 points = how many days?"

The problem: velocity (points completed per sprint) shifts with:

• Team size (people take leave, new members onboard)
• Backlog complexity (this sprint is mostly chores, that one is mostly new features)
• Interruptions (incidents, urgent fixes, meetings)
• Dependencies (waiting on an API from another team, waiting on design)

If the team says "5 points = 2 days" and you plan around that, you'll be disappointed. Use average velocity across several sprints instead of mapping each point to a fixed amount of time.

Better estimation techniques: T-shirt sizing and spikes

T-shirt sizing (S/M/L/XL): Simple, fast, less argument than story points. Great for roadmap planning when there are still a lot of unknowns.

• S: 1–2 days, clear requirements, no dependencies
• M: 3–5 days, needs some technical discovery
• L: 1–2 weeks, has dependencies and some unknowns
• XL: more than 2 weeks → should be broken into smaller stories before estimating

Spike: When an estimate has too many unknowns, don't guess — timebox an investigation. "Spike 2 days to determine feasibility and approach for feature X, then produce a tighter estimate."

A spike isn't waste — it's an investment to avoid a mid-sprint surprise. It's like a geotechnical survey before building a house: it costs an extra week up front and saves you from a collapsed foundation later.

The sources of bad estimates that a PM controls

Spec isn't clear enough: The dev has to guess at edge cases. When they hit a case the spec doesn't cover, they either interrupt to ask the PM (lost time) or decide on their own (which may be wrong and need redoing).

Scope creep: "While you're in here, just add this small X too" — the small X wasn't planned and wasn't estimated, and it's usually not as small as you think.

Changing the spec mid-sprint: Even a small change can force the dev to rework code they already wrote. Context switching (abruptly jumping to something else) is expensive in both time and mental energy.

Unconfirmed dependencies: "The other team's API will be ready Tuesday" but it's actually ready Friday → your team is blocked for 3 days with nothing to do.

The PM can't eliminate these entirely, but you can minimize them by preparing thoroughly before sprint planning.

Part 2: Technical Debt — The Price of Speed

Three kinds of technical debt

Think of technical debt like financial debt: sometimes borrowing is the right call, sometimes it's a mistake, and sometimes it's unavoidable. What matters is knowing what you owe.

Deliberate debt: A conscious decision — you know the right way but choose the fast way because of a deadline. Example: "We'll hardcode this config to make the launch, and do it properly afterward." This kind of debt is acceptable if it's well documented and there's a plan to pay it back.

Accidental debt: The dev didn't know a better way at the time they wrote the code. It surfaces as the codebase grows, as new team members join without knowing about old decisions, and as technical knowledge evolves.

Bit rot: Code that was correct when written but becomes debt as the environment changes — a library gets deprecated, an API changes, business logic shifts but the code isn't updated. No one "causes" this kind — it happens naturally over time.

Measure velocity to quantify debt

One of the most useful ways to justify investing in technical debt is to measure the velocity trend — how fast the team gets work done over time.

Example: if your team completed 40 points/sprint six months ago and now completes only 28 points/sprint with the same team size, that's a sign technical debt is getting steadily worse.

A chart of velocity declining over time is the strongest argument for allocating time to tech debt — stronger than any technical explanation when you're talking to a stakeholder.

When to pay down technical debt

Don't spend a whole sprint just "cleaning up" — there's no visible output for stakeholders, it's hard to keep the team focused, and it usually gets cancelled the moment something urgent comes up.

Do integrate debt paydown into delivery:

• Reserve 20% of each sprint's capacity for chores/refactoring
• The "Boy Scout Rule": when a dev has to touch a module for a new feature, leave it better than you found it — improve it a little, no need to refactor the whole thing
• Pay down debt before building new features on top of that module — like fixing the floor before you bring in new furniture

Part 3: Incident Response and Postmortems

Anatomy of a production incident

An incident has a fixed lifecycle — from detection to resolution:

1. Detection: An automated monitoring alert, a user report, or a dev stumbling across it
2. Triage: Determine severity — how many users are affected, which feature is broken
3. Response: The on-call dev investigates and looks for a fix
4. Mitigation: Roll back to the old version, an emergency hotfix, or a temporary workaround to reduce the impact
5. Resolution: The problem is fixed at the root
6. Postmortem: Document what happened and lay out action items

Common severity levels:

The PM should know their team's severity levels to communicate the right urgency to stakeholders — not every incident warrants an emergency email to the CEO.

The PM's role in an incident

The PM doesn't debug. But the PM is the only person in the incident channel who knows the real business impact, whether users need to be notified, and which stakeholders need updates.

Think of the PM in an incident as the crisis-communications lead in an accident: not the one doing repairs, but the one making sure accurate information reaches the right people at the right time.

Do during an incident:

• Confirm severity with the dev — how many users are affected, which feature
• Update stakeholders continuously: "Investigating," "Root cause found," "Fixing," "Resolved"
• Decide whether a status page update is needed, or an email to users
• Document the actual timeline (for the postmortem)

Don't during an incident:

• Don't ask "when will it be done?" while the dev is investigating — that's counterproductive pressure
• Don't add more people to the channel to "help" — coordination cost rises and the dev gets distracted
• Don't assign blame while the incident is still happening

Postmortem culture — why blameless isn't kindness, it's engineering

When people get blamed, the natural behavior is to hide problems to avoid blame. That makes the system less safe — problems pile up without being reported.

A blameless postmortem asks: "What system conditions led to this incident?" instead of "Who did something wrong?"

Example: Someone deployed bad code — that's a fact. But the more useful questions are: Why didn't CI/CD catch it? Why was there no canary deployment? Why didn't the rollback happen automatically?

Action items from a blameless postmortem tend to be system improvements: add test coverage, improve monitoring, improve the rollback procedure. Action items from blame tend to be "Dev X should be more careful" — unmeasurable, unverifiable, and no protection against the same incident next time.

Part 4: Communicating Effectively With the Engineering Team

Bug reports — small investment, big return

A poor bug report is one of the hidden causes of slow team velocity. Every bug report missing information needs at least one round of clarification — and each round costs 30 minutes to a few hours because of context switching.

Imagine calling an electrician and just saying "my house has an electrical problem." They'll have to ask: where? The whole house or one room? When did it start? What have you tried? A good bug report answers all of these up front.

A good bug report includes:

An actionable title: Not "Checkout page is broken" but "Checkout — 'Place Order' button disabled after adding a new shipping address on iOS Safari."

Full environment: Browser, OS, device, staging or production, the specific user account if the bug only happens for some accounts.

Steps to reproduce: Specific, step by step, repeatable. If the PM can't reproduce it while writing the report, the dev will have an even harder time.

Expected vs Actual: These two lines are the heart of the bug report. "I expected X, but I saw Y." Simple and clear.

Evidence: Screenshot, screen recording, console error (F12), Network tab error. A console error often cuts frontend debugging time in half — it's what the dev needs most, but few PMs know how to grab it.

Retrospectives — a chance to improve the process

A retrospective isn't a complaint session. It's a structured process for improving how the team works — like a review after each project so the next one goes better.

The basic format: Start / Stop / Continue

• Start: What should we do more of to help the team?
• Stop: What are we doing that adds no value?
• Continue: What's working well that we should keep?

The PM should bring data to the retro: velocity, bug count, estimate accuracy, and stakeholder feedback — not just subjective impressions. Data turns the retro into actionable output instead of a venting session.

Title: Checkout — "Place Order" button disabled after adding a new address on iOS Safari

Environment:
- Device: iPhone 13, iOS 17.2
- Browser: Safari 17
- URL: https://app.vd.com/checkout
- Environment: Production
- Account: test@example.com (or user ID if available)

Steps to reproduce:
1. Add a product to the cart
2. Go to the checkout page
3. Click "Add new address" → fill in the details → save
4. Return to the checkout form

Expected: "Place Order" button is enabled and clickable to proceed to payment
Actual: "Place Order" button is grayed out and can't be clicked

Evidence:
- [screenshot.png] — button disabled after step 4
- Console error (F12): "TypeError: Cannot read properties of null (reading 'addressId')"

Further reading

• Shape Up — Basecamp — Basecamp's product methodology, with a practical take on estimation, appetite, and working with eng. Free to read online.
• Accelerate — DORA Metrics — Research on DevOps performance: deploy frequency, lead time, MTTR, change failure rate. A basis for PMs to measure engineering team health.
• Google SRE Book — Postmortem Culture — The chapter on blameless postmortems from Google's SRE team, explaining why blame doesn't work and how postmortems should be written.
• Martin Fowler — Technical Debt — An explanation from the person who coined "technical debt": the kinds of technical debt and how to approach them.
• Atlassian — Incident Management — A practical guide to incident response process, severity levels, and postmortem templates for product teams.