Task Decomposition

Task Decomposition

Task decomposition is the process of taking a high-level goal and breaking it down into discrete, independently executable units of work. Each resulting task must satisfy the SMART criteria: Specific, Measurable, Assignable, Relevant, and Time-bound. Well-decomposed tasks are the foundation of accurate scheduling, clear ownership, and reliable delivery tracking.

When to Use This Skill

• A goal statement or requirement needs to be turned into an actionable task list.
• A deliverable is too large or vague to be assigned to a single person.
• A sprint or milestone plan needs to be populated with concrete work items.
• An existing plan has tasks that are poorly scoped or overlap with each other.
• You need to produce the ## Tasks section of a plan document.
• A team member asks: "What exactly do we need to do to achieve this?"

Prerequisites

• A written goal statement (rough draft is acceptable).
• Knowledge of the team's roles and approximate available capacity.
• Understanding of the technology or domain involved — enough to name realistic tasks.
• Access to any existing requirements documents, architecture diagrams, or previous plans.

Step-by-Step Workflow

Step 1: Understand and Restate the Goal

Read the goal statement carefully. Rewrite it in your own words, structured as:

• Objective: What must be achieved?
• Success Criteria: How will we know it is done?
• Constraints: What are the non-negotiable boundaries (deadline, technology, team size)?

Example restatement:

Goal: Build a REST API service for user authentication. Objective: Deliver a production-ready REST API handling user registration, login, token refresh, and logout. Success Criteria: All four endpoints return correct HTTP status codes, pass the agreed integration test suite, and are deployed to staging. Constraints: Must use Node.js + Express, deliver within 3 weeks, team of 2 engineers.

Step 2: Identify Top-Level Deliverables

List the major deliverables — the tangible outputs that together constitute the goal being complete. Aim for 3–7 deliverables per goal.

Technique — Noun decomposition: Ask "What artifacts, systems, or documents must exist when this is done?"

Step 3: Break Each Deliverable into Atomic Work Packages

For each deliverable, ask: "What is the smallest unit of work a single person can complete in one session?" Split until every item:

• Can be completed by ONE person.
• Has a clear done condition.
• Has a realistic duration of 30 minutes to 2 days.
• Does not contain implicit hidden sub-tasks.

Anti-pattern to avoid: "Implement authentication" is NOT atomic.

Correct decomposition:

Step 4: Apply SMART Criteria to Each Task

For every task, verify all five SMART dimensions:

Step 5: Format Tasks in the Standard Task Table

Output all tasks as a Markdown table with these exact columns:

| ID  | Task                                          | Owner       | Duration | Status      | Depends On |
|-----|-----------------------------------------------|-------------|----------|-------------|------------|
| T01 | Design POST /register request/response schema | Backend Dev | 2h       | not-started | —          |
| T02 | Implement POST /register endpoint             | Backend Dev | 4h       | not-started | T01        |
| T03 | Write unit tests for POST /register           | Backend Dev | 2h       | not-started | T02        |
| T04 | Design POST /login schema                     | Backend Dev | 1h       | not-started | T01        |
| T05 | Implement POST /login endpoint + JWT issuance | Backend Dev | 4h       | not-started | T04        |

Column rules:

• ID: Sequential, prefix T + zero-padded two-digit number: T01, T02, T10.
• Task: Verb + noun phrase. Start with an action word: Design, Implement, Write, Configure, Deploy, Review, Test.
• Owner: Role title, not a person's name (Backend Dev, QA Engineer, DevOps).
• Duration: Always include unit suffix — h for hours, d for days (e.g., 2h, 0.5d, 3d).
• Status: ONE of: not-started, in-progress, done, blocked.
• Depends On: Comma-separated task IDs, or em-dash — if none.

Step 6: Validate Completeness

Before finalizing, run this checklist:

• Every deliverable from Step 2 has at least one task assigned to it.
• No task has a duration estimate over 5 days — split further if so.
• No two tasks have identical or overlapping scope.
• Every task has a unique ID with no gaps in the sequence.
• All Depends On references point to existing task IDs in the same table.
• The task list, if executed in dependency order, would fully deliver the stated goal.

Examples

Good Pattern — Atomic, SMART Task

| T07 | Configure Dockerfile for Node.js API service | DevOps | 3h | not-started | T06 |

• Specific: Exactly what is being configured (Dockerfile, Node.js API service).
• Measurable: Done when docker build succeeds locally and image starts correctly.
• Assignable: DevOps owns it exclusively.
• Relevant: Required for the deployment pipeline deliverable.
• Time-bound: 3 hours.

Bad Pattern — Vague, Non-atomic Task

| T07 | Set up infrastructure | DevOps | 2w | not-started | T06 |

Problems:

• "Set up infrastructure" could mean 20 different things.
• 2 weeks is too long — no visibility into daily progress.
• No done condition defined.
• Untestable in a standup.

Fix: Split into separate rows — configure Dockerfile (3h), write docker-compose.yml (2h), configure CI pipeline (4h), provision staging server (2h), write deployment runbook (2h).

Good Pattern — Complete Task Table

| ID  | Task                                    | Owner       | Duration | Status      | Depends On |
|-----|-----------------------------------------|-------------|----------|-------------|------------|
| T01 | Write OpenAPI spec for all 4 endpoints  | Backend Dev | 4h       | not-started | —          |
| T02 | Scaffold Express app + folder structure | Backend Dev | 2h       | not-started | T01        |
| T03 | Implement POST /register                | Backend Dev | 4h       | in-progress | T02        |
| T04 | Write integration tests for /register   | QA Engineer | 3h       | not-started | T03        |

Troubleshooting

References

• SMART criteria: Doran, G.T. (1981). "There's a S.M.A.R.T. way to write management's goals and objectives." — Management Review 70(11).
• Work Breakdown Structure (WBS): PMI PMBOK Guide, 7th Edition, Section 5.4.
• Agile task sizing: Mike Cohn, Agile Estimating and Planning, Chapter 5.