gh-tommy-ca-notion-skills-plugins-notion-skills/skills/spec-to-implementation/reference/task-breakdown-guide.md

Spec to Implementation - Task Breakdown Guide

How to decompose specifications into well-structured, implementable tasks.

Task Hierarchy

Specification Document
├── Requirement 1
│   ├── User Story 1.1
│   │   ├── Task 1.1.1 (Backend)
│   │   ├── Task 1.1.2 (Frontend)
│   │   └── Task 1.1.3 (Testing)
│   └── User Story 1.2
│       └── [Tasks...]
└── Requirement 2
    └── [User Stories and Tasks...]

Task Properties

Each task should have:

Property	Purpose	Example
Title	Clear, action-oriented	"Implement user authentication endpoint"
Description	What, why, how	Details of implementation approach
Acceptance Criteria	How to know it's done	"Users can log in with email/password"
Estimate	Effort required	"5 story points" or "8 hours"
Owner	Who's doing it	"Alex Chen"
Dependencies	What must happen first	"Database schema finalized"
Priority	Urgency	"P0 - Blocking", "P1 - Critical", etc.

Task Sizing

Too Large (> 3 days)

• Hard to estimate accurately
• Difficult to track progress
• Risk of getting blocked

Right Size (1-2 days)

• Concrete and actionable
• Progress visible daily
• Easier to unblock

Too Small (< 2 hours)

• Overhead from task management
• Discourages good estimates
• Creates task clutter

Task Types

Backend Implementation

Task: Implement [feature] endpoint

Acceptance Criteria:
- [ ] Endpoint accepts [inputs]
- [ ] Returns [format] with [fields]
- [ ] Validates [constraints]
- [ ] Handles [error cases]
- [ ] Tests cover [coverage level]%

Frontend Implementation

Task: Build [component/page]

Acceptance Criteria:
- [ ] Component renders [expected layout]
- [ ] Responds to [user interactions]
- [ ] Displays [content] from API
- [ ] Works on [screen sizes]
- [ ] Accessible (WCAG [level])

Database/Data

Task: Create [schema/migration]

Acceptance Criteria:
- [ ] Schema supports [use cases]
- [ ] Indexes created for [queries]
- [ ] Migration handles [data]
- [ ] Rollback plan documented
- [ ] Performance tested

Testing

Task: Test [feature/component]

Acceptance Criteria:
- [ ] Unit tests: [X]% coverage
- [ ] Integration tests for [scenarios]
- [ ] End-to-end tests for [flows]
- [ ] Performance tests meet [targets]
- [ ] Documented edge cases

Documentation

Task: Document [feature/API]

Acceptance Criteria:
- [ ] API documentation complete
- [ ] Usage examples included
- [ ] Edge cases documented
- [ ] Links to related docs added
- [ ] Reviewed and approved

Dependency Mapping

Identify blocking dependencies:

Auth Implementation (5 days)
├── Database schema (2 days) ← Must happen first
├── API endpoint (3 days) ← Depends on schema
├── Frontend UI (2 days) ← Depends on endpoint
└── Testing (2 days) ← Depends on frontend

Critical Path: Schema → Endpoint → Frontend → Testing (11 days)

Parallel Work: Multiple features can start once dependencies met

Effort Estimation

Estimation Techniques:

1. Story Points (Fibonacci: 1, 2, 3, 5, 8, 13)

   • Relative sizing
   • Good for iterative planning
   • Accounts for uncertainty

2. Hours (for precise tracking)

   • 4-6 hours = Small task
   • 8-16 hours = Medium task
   • 16+ hours = Break down further

3. Days (for roadmapping)

   • 1 day = Sprint task
   • 2-3 days = Normal task
   • 4+ days = Risky, reconsider

Acceptance Criteria Format

Good Acceptance Criteria:

Given [context]
When [action happens]
Then [expected result]

Example:

Given user is on the login page
When they enter email and click submit without password
Then they see error "Password is required"

Common Decomposition Patterns

By Component

• Task 1: Implement backend service
• Task 2: Build UI component
• Task 3: Integrate frontend to backend
• Task 4: Test end-to-end

By Feature Slice

• Task 1: Happy path implementation
• Task 2: Error handling
• Task 3: Edge cases
• Task 4: Performance optimization

By Layer

• Task 1: Database layer
• Task 2: API layer
• Task 3: Frontend layer
• Task 4: Integration & testing

By Priority

• Task 1: MVP features
• Task 2: Core features
• Task 3: Nice-to-haves
• Task 4: Future enhancements

Red Flags

⚠️ Task is too vague

• "Fix authentication" → Break down to specific changes

⚠️ Task has unclear owner

• Ensure one person is clearly responsible

⚠️ Task has no acceptance criteria

• Add specific, measurable completion definition

⚠️ Task is estimated at 13+ points

• Break into smaller tasks

⚠️ Task has unidentified dependencies

• List all blockers explicitly

⚠️ Task depends on another task being done

• Create clear sequence or parallelize where possible

Task Lifecycle

Spec Analysis
↓
Task Identification
↓
Dependency Mapping
↓
Prioritization & Sequencing
↓
Estimation
↓
Assignment
↓
Implementation (with daily progress)
↓
Review & Testing
↓
Completion & Documentation

Documentation in Task Manager

Each task should link to:

• Original specification
• Related tasks
• Design documentation
• Test cases
• Code review URL
• Merged PR/commit