Ticket Analysis — Tech Lead Perspective

When to Activate

• Analyzing a ticket backlog for sprint planning
• Prioritizing team demands
• Identifying blockers and dependencies between tasks
• Estimating effort for stakeholders
• Preparing for a refinement meeting

Effort Scoring (modified Fibonacci)

Pts	Criteria	Examples
1	Config, text, isolated variable	Feature flag, copy change, env var
2	Isolated bugfix, simple route	Validation fix, read endpoint
3	Small feature, clear scope	Entity CRUD, simple new screen
5	Medium feature, multiple components	API integration, complete flow
8	High uncertainty or architectural impact	Break down before estimating

Golden rule: More than 2 minutes to estimate = ticket needs refinement first.

Priority Matrix (adapted Eisenhower)

              URGENT        NOT URGENT
HIGH IMPACT   P0 🔴          P1 🟡
              Do now         Plan next sprint
              (blocks team   (strategic value)
              or production)

LOW IMPACT    P2 🟠          P3 ⚪
              Delegate or    Backlog / reject /
              quick fix      icebox

Urgency: production impact, team blocker, external deadline Impact: user value, debt reduction, risk mitigated

Technical Flags

For each ticket, check:

Flag	Meaning	Action
🔄 Dep	Blocks or is blocked by another ticket	Map dependency graph
🏗️ Arch	Requires architectural decision before coding	Add spike/ADR to planning
⚠️ Risk	Sensitive area (auth, billing, core, data)	Extra review, regression tests
🌀 Vague	Scope may grow during execution	Refine before accepting into the sprint
✂️ Split	Ticket > 5 pts that can be broken down	Propose split into sub-tasks
🔬 Spike	High technical uncertainty	Reserve time for investigation

Standard Output

Always produce the analysis with this structure:

## Ticket Analysis — [YYYY-MM-DD]

### Executive Summary
- Total analyzed: N tickets
- P0 (critical): X | P1 (planned): Y | P2 (delegable): Z | P3 (backlog): W
- Total estimated effort: X pts (~Y dev-days)
- Blockers identified: Z

### 🔴 P0 — Do Now

**#[ID] — [Title]**
- Effort: X pts | Risk: High/Medium/Low
- Blocking: #IDs (or "none")
- Flags: [list of relevant flags]
- Recommended action: [specific instruction for the dev]

### 🟡 P1 — Next Sprint
[same structure per ticket]

### 🟠 P2 — Delegate / Quick Fix
[compact list with delegation rationale]

### ⚪ P3 — Backlog / Reject
[list with reason: low impact, duplicate, out of scope]

### Dependency Map

```text
ID_A → ID_B (A blocks B)
ID_B → ID_C
```

### Risks & Blockers
- **[Risk]**: [description] → Mitigation: [action]

### Recommendations for the Tech Lead
1. [specific tactical action]
2. [required stakeholder communication]
3. [capacity / priority adjustment]

Tech Lead Perspective

When analyzing, always consider:

• Team capacity: what is realistic for the sprint given the current context?
• Technical debt: does the ticket add or reduce debt?
• Definition of Done: are the acceptance criteria clear?
• Communication: do stakeholders need to be notified of priority changes?
• Onboarding: is the ticket suitable for a junior dev or does it require a senior?