Task Breakdown - Value-Driven Decomposition
Foundational Principle
Every task must deliver working software that provides measurable user value.
Creating technical-only or oversized tasks creates:
- Work that doesn't ship until "everything is done"
- Teams working on pieces that don't integrate
- No early validation of value or technical approach
- Waterfall development disguised as iterative process
Tasks answer: What working increment will be delivered?
Tasks never answer: How to implement that increment (that's Subtasks).
Mandatory Workflow
| Phase |
Activities |
| 1. Task Identification |
Load PRD (Gate 1, required), TRD (Gate 3, required); optional: Feature Map, API Design, Data Model, Dependency Map; identify value streams |
| 2. Decomposition |
Per component/feature: define deliverable, set success criteria, map dependencies, estimate effort (S/M/L/XL max=2 weeks), plan testing, identify risks |
| 3. Gate 7 Validation |
All TRD components covered; every task delivers working software; measurable success criteria; correct dependencies; no task >2 weeks; testing strategy defined; risks with mitigations; delivery sequence optimizes value |
Explicit Rules
✅ DO Include in Tasks
Task ID, title, type (Foundation/Feature/Integration/Polish), deliverable (what ships), user value (what users can do), technical value (what it enables), success criteria (testable/measurable), dependencies (blocks/requires/optional), effort estimate (S/M/L/XL with points), testing strategy, risk identification with mitigations, Definition of Done checklist
❌ NEVER Include in Tasks
Implementation details (file paths, code examples), step-by-step instructions (those go in subtasks), technical-only tasks with no user value, tasks exceeding 2 weeks (break them down), vague success criteria ("improve performance"), missing dependency information, undefined testing approach
Task Sizing Rules
| Size |
Points |
Duration |
Scope |
| Small (S) |
1-3 |
1-3 days |
Single component |
| Medium (M) |
5-8 |
3-5 days |
Few dependencies |
| Large (L) |
13 |
1-2 weeks |
Multiple components |
| XL (>2 weeks) |
BREAK IT DOWN |
Too large |
Not atomic |
Value Delivery Rules
- Foundation: Enables other work (database setup, core services)
- Feature: Delivers user-facing capabilities
- Integration: Connects to external systems
- Polish: Optimizes or enhances (nice-to-have)
Rationalization Table
| Excuse |
Reality |
| "This 3-week task is fine" |
Tasks >2 weeks hide complexity. Break it down. |
| "Setup tasks don't need value" |
Setup enables value. Define what it enables. |
| "Success criteria are obvious" |
Obvious to you ≠ testable. Document explicitly. |
| "Dependencies will be clear later" |
Later is too late. Map them now. |
| "We don't need detailed estimates" |
Without estimates, no planning possible. Size them. |
| "Technical tasks can skip user value" |
Even infrastructure enables users. Define the connection. |
| "Testing strategy can be decided during" |
Testing affects design. Plan it upfront. |
| "Risks aren't relevant at task level" |
Risks compound across tasks. Identify them early. |
| "DoD is the same for all tasks" |
Different tasks need different criteria. Specify. |
| "We can combine multiple features" |
Combining hides value delivery. Keep tasks focused. |
Red Flags - STOP
If you catch yourself writing any of these in a task, STOP:
- Task estimates over 2 weeks
- Tasks named "Setup X" without defining what X enables
- Success criteria like "works" or "complete" (not measurable)
- No dependencies listed (every task depends on something)
- No testing strategy (how will you verify?)
- "Technical debt" as a task type (debt reduction must deliver value)
- Vague deliverables ("improve", "optimize", "refactor")
- Missing Definition of Done
When you catch yourself: Refine the task until it's concrete, valuable, and testable.
Gate 7 Validation Checklist
| Category |
Requirements |
| Task Completeness |
All TRD components have tasks; all PRD features have tasks; each task appropriately sized (no XL+); task boundaries clear |
| Delivery Value |
Every task delivers working software; user value explicit; technical value clear; sequence optimizes value |
| Technical Clarity |
Success criteria measurable/testable; dependencies correctly mapped; testing approach defined; DoD comprehensive |
| Team Readiness |
Skills match capabilities; estimates realistic; capacity available; handoffs minimized |
| Risk Management |
Risks identified per task; mitigations defined; high-risk tasks scheduled early; fallback plans exist |
Gate Result: ✅ PASS → Subtasks | ⚠️ CONDITIONAL (refine oversized/vague) | ❌ FAIL (re-decompose)
Task Template Structure
Output to docs/pre-dev/{feature-name}/tasks.md. Each task includes:
| Section |
Content |
| Header |
T-[XXX]: [Task Title - What It Delivers] |
| Deliverable |
One sentence: what working software ships |
| Scope |
Includes (specific capabilities), Excludes (future tasks with IDs) |
| Success Criteria |
Testable items: Functional, Technical, Operational, Quality |
| User/Technical Value |
What users can do; what this enables |
| Technical Components |
From TRD, From Dependencies |
| Dependencies |
Blocks (T-AAA), Requires (T-BBB), Optional (T-CCC) |
| Effort Estimate |
Size (S/M/L/XL), Points, Duration, Team type |
| Risks |
Per risk: Impact, Probability, Mitigation, Fallback |
| Testing Strategy |
Unit, Integration, E2E, Performance, Security |
| Definition of Done |
Code reviewed, tests passing, docs updated, security clean, performance met, deployed to staging, PO acceptance, monitoring configured |
Common Violations
| Violation |
Wrong |
Correct |
| Technical-Only Tasks |
"Setup PostgreSQL Database" with install/configure steps |
"User Data Persistence Foundation" with deliverable (working DB layer <100ms), user value (enables T-002/T-003), success criteria (users table, pooling, migrations) |
| Oversized Tasks |
"Complete User Management System" (6 weeks) with all auth features combined |
Split into: T-005 Basic Auth (L), T-006 Password Mgmt (M), T-007 2FA (M), T-008 Permissions (L) |
| Vague Success Criteria |
"Feature works, Tests pass, Code reviewed" |
Functional (upload 100MB, formats), Technical (<2s response), Operational (99.5% success rate), Quality (90% coverage) |
Delivery Sequencing
Optimize task order by sprint/phase with goals, critical path identification, and parallel work opportunities.
Confidence Scoring
| Factor |
Points |
Criteria |
| Task Decomposition |
0-30 |
All appropriately sized: 30, Most well-scoped: 20, Too large/vague: 10 |
| Value Clarity |
0-25 |
Every task delivers working software: 25, Most clear: 15, Unclear: 5 |
| Dependency Mapping |
0-25 |
All documented: 25, Most clear: 15, Ambiguous: 5 |
| Estimation Quality |
0-20 |
Based on past work: 20, Educated guesses: 12, Speculation: 5 |
Action: 80+ autonomous | 50-79 present options | <50 ask about velocity
Output & After Approval
Output to: docs/pre-dev/{feature-name}/tasks.md
- ✅ Tasks become sprint backlog
- 🎯 Use as input for subtasks (
ring:pre-dev-subtask-creation)
- 📊 Track progress per task (not per subtask)
- 🚫 No implementation yet - that's in subtasks
The Bottom Line
If you created tasks that don't deliver working software, rewrite them.
Tasks are not technical activities. Tasks are working increments.
"Setup database" is not a task. "User data persists correctly" is a task.
"Implement OAuth" is not a task. "Users can log in with Google" is a task.
"Write tests" is not a task. Tests are part of Definition of Done for other tasks.
Every task must answer: "What working software can I demo to users?"
If you can't demo it, it's not a task. It's subtask implementation detail.
Deliver value. Ship working software. Make tasks demoable.
1---2name: ring-pre-dev-task-breakdown3description: Gate 7: Implementation tasks - value-driven decomposition into working increments that deliver measurable user value.4---5
6# Task Breakdown - Value-Driven Decomposition
7
8## Foundational Principle
9
10**Every task must deliver working software that provides measurable user value.**
11
12Creating technical-only or oversized tasks creates:
13- Work that doesn't ship until "everything is done"
14- Teams working on pieces that don't integrate
15- No early validation of value or technical approach
16- Waterfall development disguised as iterative process
17
18**Tasks answer**: What working increment will be delivered?
19**Tasks never answer**: How to implement that increment (that's Subtasks).
20
21## Mandatory Workflow
22
23| Phase | Activities |
24|-------|------------|
25| **1. Task Identification** | Load PRD (Gate 1, required), TRD (Gate 3, required); optional: Feature Map, API Design, Data Model, Dependency Map; identify value streams |
26| **2. Decomposition** | Per component/feature: define deliverable, set success criteria, map dependencies, estimate effort (S/M/L/XL max=2 weeks), plan testing, identify risks |
27| **3. Gate 7 Validation** | All TRD components covered; every task delivers working software; measurable success criteria; correct dependencies; no task >2 weeks; testing strategy defined; risks with mitigations; delivery sequence optimizes value |
28
29## Explicit Rules
30
31### ✅ DO Include in Tasks
32Task ID, title, type (Foundation/Feature/Integration/Polish), deliverable (what ships), user value (what users can do), technical value (what it enables), success criteria (testable/measurable), dependencies (blocks/requires/optional), effort estimate (S/M/L/XL with points), testing strategy, risk identification with mitigations, Definition of Done checklist
33
34### ❌ NEVER Include in Tasks
35Implementation details (file paths, code examples), step-by-step instructions (those go in subtasks), technical-only tasks with no user value, tasks exceeding 2 weeks (break them down), vague success criteria ("improve performance"), missing dependency information, undefined testing approach
36
37### Task Sizing Rules
38
39| Size | Points | Duration | Scope |
40|------|--------|----------|-------|
41| Small (S) | 1-3 | 1-3 days | Single component |
42| Medium (M) | 5-8 | 3-5 days | Few dependencies |
43| Large (L) | 13 | 1-2 weeks | Multiple components |
44| XL (>2 weeks) | BREAK IT DOWN | Too large | Not atomic |
45
46### Value Delivery Rules
47- **Foundation**: Enables other work (database setup, core services)
48- **Feature**: Delivers user-facing capabilities
49- **Integration**: Connects to external systems
50- **Polish**: Optimizes or enhances (nice-to-have)
51
52## Rationalization Table
53
54| Excuse | Reality |
55|--------|---------|
56| "This 3-week task is fine" | Tasks >2 weeks hide complexity. Break it down. |
57| "Setup tasks don't need value" | Setup enables value. Define what it enables. |
58| "Success criteria are obvious" | Obvious to you ≠ testable. Document explicitly. |
59| "Dependencies will be clear later" | Later is too late. Map them now. |
60| "We don't need detailed estimates" | Without estimates, no planning possible. Size them. |
61| "Technical tasks can skip user value" | Even infrastructure enables users. Define the connection. |
62| "Testing strategy can be decided during" | Testing affects design. Plan it upfront. |
63| "Risks aren't relevant at task level" | Risks compound across tasks. Identify them early. |
64| "DoD is the same for all tasks" | Different tasks need different criteria. Specify. |
65| "We can combine multiple features" | Combining hides value delivery. Keep tasks focused. |
66
67## Red Flags - STOP
68
69If you catch yourself writing any of these in a task, **STOP**:
70
71- Task estimates over 2 weeks
72- Tasks named "Setup X" without defining what X enables
73- Success criteria like "works" or "complete" (not measurable)
74- No dependencies listed (every task depends on something)
75- No testing strategy (how will you verify?)
76- "Technical debt" as a task type (debt reduction must deliver value)
77- Vague deliverables ("improve", "optimize", "refactor")
78- Missing Definition of Done
79
80**When you catch yourself**: Refine the task until it's concrete, valuable, and testable.
81
82## Gate 7 Validation Checklist
83
84| Category | Requirements |
85|----------|--------------|
86| **Task Completeness** | All TRD components have tasks; all PRD features have tasks; each task appropriately sized (no XL+); task boundaries clear |
87| **Delivery Value** | Every task delivers working software; user value explicit; technical value clear; sequence optimizes value |
88| **Technical Clarity** | Success criteria measurable/testable; dependencies correctly mapped; testing approach defined; DoD comprehensive |
89| **Team Readiness** | Skills match capabilities; estimates realistic; capacity available; handoffs minimized |
90| **Risk Management** | Risks identified per task; mitigations defined; high-risk tasks scheduled early; fallback plans exist |
91
92**Gate Result:** ✅ PASS → Subtasks | ⚠️ CONDITIONAL (refine oversized/vague) | ❌ FAIL (re-decompose)
93
94## Task Template Structure
95
96Output to `docs/pre-dev/{feature-name}/tasks.md`. Each task includes:
97
98| Section | Content |
99|---------|---------|
100| **Header** | T-[XXX]: [Task Title - What It Delivers] |
101| **Deliverable** | One sentence: what working software ships |
102| **Scope** | Includes (specific capabilities), Excludes (future tasks with IDs) |
103| **Success Criteria** | Testable items: Functional, Technical, Operational, Quality |
104| **User/Technical Value** | What users can do; what this enables |
105| **Technical Components** | From TRD, From Dependencies |
106| **Dependencies** | Blocks (T-AAA), Requires (T-BBB), Optional (T-CCC) |
107| **Effort Estimate** | Size (S/M/L/XL), Points, Duration, Team type |
108| **Risks** | Per risk: Impact, Probability, Mitigation, Fallback |
109| **Testing Strategy** | Unit, Integration, E2E, Performance, Security |
110| **Definition of Done** | Code reviewed, tests passing, docs updated, security clean, performance met, deployed to staging, PO acceptance, monitoring configured |
111
112## Common Violations
113
114| Violation | Wrong | Correct |
115|-----------|-------|---------|
116| **Technical-Only Tasks** | "Setup PostgreSQL Database" with install/configure steps | "User Data Persistence Foundation" with deliverable (working DB layer <100ms), user value (enables T-002/T-003), success criteria (users table, pooling, migrations) |
117| **Oversized Tasks** | "Complete User Management System" (6 weeks) with all auth features combined | Split into: T-005 Basic Auth (L), T-006 Password Mgmt (M), T-007 2FA (M), T-008 Permissions (L) |
118| **Vague Success Criteria** | "Feature works, Tests pass, Code reviewed" | Functional (upload 100MB, formats), Technical (<2s response), Operational (99.5% success rate), Quality (90% coverage) |
119
120## Delivery Sequencing
121
122Optimize task order by sprint/phase with goals, critical path identification, and parallel work opportunities.
123
124## Confidence Scoring
125
126| Factor | Points | Criteria |
127|--------|--------|----------|
128| Task Decomposition | 0-30 | All appropriately sized: 30, Most well-scoped: 20, Too large/vague: 10 |
129| Value Clarity | 0-25 | Every task delivers working software: 25, Most clear: 15, Unclear: 5 |
130| Dependency Mapping | 0-25 | All documented: 25, Most clear: 15, Ambiguous: 5 |
131| Estimation Quality | 0-20 | Based on past work: 20, Educated guesses: 12, Speculation: 5 |
132
133**Action:** 80+ autonomous | 50-79 present options | <50 ask about velocity
134
135## Output & After Approval
136
137**Output to:** `docs/pre-dev/{feature-name}/tasks.md`
138
1391. ✅ Tasks become sprint backlog
1402. 🎯 Use as input for subtasks (`ring:pre-dev-subtask-creation`)
1413. 📊 Track progress per task (not per subtask)
1424. 🚫 No implementation yet - that's in subtasks
143
144## The Bottom Line
145
146**If you created tasks that don't deliver working software, rewrite them.**
147
148Tasks are not technical activities. Tasks are working increments.
149
150"Setup database" is not a task. "User data persists correctly" is a task.
151"Implement OAuth" is not a task. "Users can log in with Google" is a task.
152"Write tests" is not a task. Tests are part of Definition of Done for other tasks.
153
154Every task must answer: **"What working software can I demo to users?"**
155
156If you can't demo it, it's not a task. It's subtask implementation detail.
157
158**Deliver value. Ship working software. Make tasks demoable.**
majiayu000