Task Decomposition

A good task is:

• Completable in one session — If it takes more, break it down further
• Independently testable — Can be verified without other tasks
• Clearly scoped — Developer knows exactly what files to touch
• Has clear done criteria — Unambiguous definition of complete

Size Guidelines

Step 3: Define Dependencies

Map which tasks must complete before others can start:

TASK-001 (data model) ─┬─▶ TASK-003 (API endpoint)
TASK-002 (auth logic)  ─┘         │
                                  ▼
                          TASK-004 (integration tests)

Mark dependent tasks in their descriptions. Assign upstream tasks first.

Step 4: Write Acceptance Criteria

Each task needs:

1. Given — Starting conditions and context
2. When — The action or change being made
3. Then — Expected outcome, verifiable result

Example:

Given: User model exists with email field
When: Login endpoint receives valid credentials
Then: Returns JWT token with 24h expiry and user profile

Task Assignment Guidelines

Common Decomposition Patterns

New Feature

1. Define data model → Developer
2. Implement business logic → Developer
3. Create API endpoint → Developer
4. Write unit tests → Integrator
5. Write e2e tests → Integrator
6. Update documentation → Architect

Bug Fix

1. Reproduce and document → Developer
2. Implement fix → Developer
3. Add regression test → Integrator
4. Verify fix → Architect (review)

Refactoring

1. Document current behavior with tests → Integrator
2. Refactor implementation → Developer
3. Verify tests still pass → Integrator
4. Review architecture impact → Architect