Frontend Team Management Playbook

How I lead, plan, and deliver as a Senior/Lead Frontend Developer using agile practices, clear communication, and strong mentoring.

1) Requirement Intake

  • • Align with PM/PO on scope, priorities, acceptance criteria, risks.
  • • Clarify non-functionals: performance, SEO, accessibility, analytics.
  • • Identify dependencies with backend, design, and infra.
0% clarity

2) Breakdown & Estimation

  • • Break epics → stories → tasks/subtasks with clear DoD.
  • • Estimate with team (story points or hours); surface risks.
  • • Define milestones, demo plan, and test strategy.
Auth UI
3 SP
API Integration
5 SP
E2E Tests
2 SP
Total: 10 SPETA ≈ 2 day(s)

3) Delegation & Ownership

  • • Assign tasks based on strengths and growth goals of juniors.
  • • Provide acceptance criteria, mockups, API contracts, examples.
  • • Set clear expectations for code style, tests, and timelines.
UI
API
Tests
Load looks balanced

4) Jira Workflow

  • • Columns: Backlog → Selected → In Progress → Code Review → Testing → Done.
  • • Use Epics, Components, Labels (feature, bug, tech-debt).
  • • Automations: PR linked on transition, reviewers auto-assigned.
Backlog
TG-123: Feature slice
Selected
In Progress
Review
Testing
Done

5) Code Quality & Reviews

  • • PR template: context, screenshots, test notes, risk/rollback.
  • • Standards: TypeScript strictness, accessibility, SEO, performance.
  • • Tests where valuable (unit/Jest, E2E/Playwright for flows).
TypeScript
Accessibility
SEO
Unit tests

6) Rituals & Communication

  • • Daily standup: blockers, priorities, handoffs.
  • • Weekly planning/refinement; bi-weekly demo/retro.
  • • Async updates via Jira + Discord; design/BE syncs as needed.

Mentoring Juniors

  • • Pair programming and design walkthroughs for complex tasks.
  • • Provide learning paths: React/Next.js, TypeScript, Tailwind, SEO.
  • • Gradual responsibility: from UI tickets → feature ownership → PR reviews.
  • • Share playbooks for debugging, performance, accessibility.
Growth: 35%

Definition of Done (DoD)

  • • Meets acceptance criteria; passes reviews and tests.
  • • Accessible, responsive, and SEO-checked.
  • • Monitored post-release; issues triaged in Jira.
0% DoD complete

Deadline Decision Framework

Balance business urgency with engineering reality. Start from scope and capacity, then add risk buffers. If a fixed date is mandatory, negotiate scope and quality gates.

8
5
3
2
70%
20%
Total SP
16
Team velocity
8/day
Raw estimate
2 days
With buffer
3 days

Criteria to set a realistic deadline

  • Scope clarity and acceptance criteria maturity
  • Dependencies readiness (design, APIs, infra)
  • Team capacity and focus factor (meetings, support load)
  • Complexity and risk profile (new tech, migrations)
  • Non-functional requirements (performance, SEO, a11y)
  • Testing depth and release strategy (staged, feature flags)

When date is fixed (negotiation levers)

  • De-scope to a Minimum Lovable Product (MLP)
  • Stage delivery: Phase 1 (core), Phase 2 (enhancements)
  • Relax non-crit NFRs temporarily; harden post-release
  • Add capacity (cross-team support, overtime as last resort)
  • Use feature flags to ship safely and iterate
  • Align on risk acceptance explicitly with stakeholders