Phase 2: Tactical Planning + Critical Transfer

Complete Example: User Story → Tactical Plan

Initial User Story (Product Owner)

As a user,
I want to see prediction confidence with each result
So that I can evaluate the reliability of recommendations

Acceptance Criteria:
- Confidence score 0-100% displayed clearly
- Explanation of factors influencing confidence
- Visual indicator (green/yellow/red) according to level

Phase 1: Architecture Vision (Designer)

Decision: Place confidence logic in business layer, integrate with existing recommendation pipeline. ADR: Sample size penalty to avoid overconfidence.

Phase 2A: Tactical Plan Generated (LLM)

Decomposition into 3 components:

Component 1: confidence_calculator

• Responsibility: Calculate raw confidence score with penalties
• Inputs:
  • weighted_presence: float - Sum (similarity × presence)
  • total_similarity: float - Sum of similarity scores
  • n_contributors: int - Number of contributor items
  • top_k_similar: int - Target count (typically 5)
• Outputs:
  • confidence_score: float - Score [0, 1]
• Dependencies: None (pure module, testable in isolation)
• Algorithm:
  1. Calculate raw confidence: weighted_presence / total_similarity
  2. Sample size penalty: min(n_contributors / top_k, 1.0)
  3. Statistical penalty if n < 3: 0.5 + (n / 6.0)
  4. Return: confidence × penalties

Component 2: confidence_explainer

• Responsibility: Generate explanation of confidence factors
• Inputs:
  • confidence_score: float
  • n_contributors: int
  • top_k_similar: int
• Outputs:
  • explanation: str - Explanatory text
  • factors: List[str] - List of key factors
• Dependencies: None
• Logic:
  • If n < 3: “Very small sample, reduced confidence”
  • If n < top_k: “Limited data, {n}/{top_k} sources”
  • If score > 0.8: “Strong confidence, many concordant sources”

Component 3: confidence_presenter

• Responsibility: Format for UI (color, text)
• Inputs:
  • confidence_score: float
  • explanation: str
• Outputs:
  • display_data: Dict - {score_percent, color, label, explanation}
• Dependencies: None
• Color mapping:
  • score ≥ 0.8: Green (#10b981)
  • score 0.5-0.8: Yellow (#fbbf24)
  • score < 0.5: Red (#ef4444)

Integration sequence:

# In existing recommendation pipeline
score = confidence_calculator.calculate(...)
explanation = confidence_explainer.explain(score, ...)
display = confidence_presenter.format(score, explanation)

Phase 2B: Critical Transfer - Discussion Example

Team Question (Backend Dev): “Will the penalty calculation be fast enough in production? We generate 1000+ recommendations per request.”

Designer Response: “Good question. The calculation is O(1)—just simple arithmetic. No I/O, no loops. Should be < 1ms per calculation. We can profile in Phase 4 to confirm.”

Plan Revision: Add performance benchmark to Phase 3 tests.

Team Question (Frontend Dev): “For free users, should we hide the confidence score? It could be a premium feature.”

Product Owner Discussion: “Interesting. For MVP, let’s show it to everyone. We can A/B test premium later.”

Plan Revision: None. Noted for future backlog.

Team Question (Senior Dev): “What happens if the external API that calculates similarity is down? Will the confidence score be 0?”

Designer Response: “Exactly. If API is down, no similarity → confidence_calculator returns 0. We need to handle this upstream with fallback or cache.”

Plan Revision: Add error handling to confidence_calculator spec—return 0.0 explicitly if total_similarity ≤ 0, with warning logging.

Final Estimates:

• Designer: “3 simple modules, 6-8h total”
• Team: “With tests and refactoring, more like 8-10h”
• Alignment: 8-10h retained (11% variance, < 20% ✓)

Recommended Prompts

Tactical Plan Generation (Phase 2A)

Generate a detailed tactical implementation plan for this User Story:

USER STORY:
[paste complete User Story with acceptance criteria]

STRATEGIC ARCHITECTURE (context):
[paste relevant Phase 1 ADRs and decisions]

TECHNICAL CONSTRAINTS:
- Stack: Python 3.11+, FastAPI
- Standards: Type hints mandatory, 90%+ test coverage
- Performance: <100ms API endpoint latency

DECOMPOSE into 3-5 components with FOR EACH component:

1. **Component Name** (snake_case)
2. **Responsibility**: One clear sentence of role
3. **Inputs**: Precise types, meaning, constraints
4. **Outputs**: Precise types, format, constraints
5. **Dependencies**: Which other components/services required
6. **Algorithm/Logic**: Main steps (not code, description)
7. **Quality Criteria**: Complexity, performance, testability

THEN:
- **Integration Sequence**: How components assemble
- **Critical Interfaces**: Integration points with existing system
- **Identified Risks**: Technical, performance, dependencies

Format: Structured markdown, clear, unambiguous.

Revision Post-Critical Transfer

Revise this tactical plan incorporating Critical Transfer feedback:

ORIGINAL TACTICAL PLAN:
[paste plan generated in Phase 2A]

TEAM FEEDBACK (Critical Transfer):
[paste discussion notes - questions, concerns, proposed revisions]

DECISIONS MADE:
[paste decisions - what is accepted, rejected, modified]

GENERATE REVISED tactical plan with:
1. Modifications explicitly marked and integrated
2. Responses to concerns documented
3. Additional identified risks added
4. Updated estimates if applicable

Format: Same structure as original plan, with "REVISED:" sections for changes.

Quality Standards

Good Tactical Plan

Characteristics:

• Decoupled components: Each module testable in isolation, minimal dependencies
• Clear interfaces: Explicit inputs/outputs, well-defined contracts
• Logical sequence: Implementation order obvious (dependencies → consuming components)
• Unambiguous specifications: Not vague “handle errors,” but “raise ValueError if x < 0”
• Estimable: Team can estimate effort for each component

Example:

Module: user_validator
Inputs: email: str, age: int
Outputs: ValidationResult(valid: bool, errors: List[str])
Logic:
  1. Verify email format (RFC 5322 regex)
  2. Verify age in [13, 120]
  3. Return result with specific errors

Poor Tactical Plan

Problems:

• Tight coupling: Module A directly calls Module B’s private methods
• Circular dependencies: A depends on B, B depends on A
• Vague specs: “Validate user” without details, “Handle edge cases”
• Incoherent order: Components ordered randomly, not by dependencies
• Impossible to estimate: “User management module” too large/vague

Example:

Module: user_manager
Inputs: user_data (unspecified format)
Outputs: Result (unspecified type)
Logic: Manage users and their data

→ Too vague, impossible to implement

Common Pitfalls

1. Passive Team at Critical Transfer

Problem: Team approves everything without questions. Silence = tacit approval. Designer thinks “everything is clear,” but team is just afraid to question.

Solution:

• Create psychological safety: Designer explicitly says “I WANT your questions, even ‘dumb’ ones”
• Ask direct questions: “Backend Dev, what do you think about external API error handling?”
• Red flag if zero questions: Silent team = problem. Dig into why.

2. Plan Too Detailed (Over-Engineering)

Problem: LLM generates plan with 15 microservices components, complex design patterns, premature abstractions. Team overwhelmed.

Solution:

• 3-5 component rule: Maximum 5 modules for typical user story
• Strict YAGNI: “You Aren’t Gonna Need It”—only what serves this story
• Designer filters: Validates appropriate complexity for problem

Prompt adjustment:

Decompose into 3-5 SIMPLE components.
YAGNI principle: generate ONLY what serves this story.
No premature abstractions, no complex patterns.
Simple code > clever code.

3. Divergent Estimates Not Reconciled

Problem: Designer estimates 6h, Team estimates 15h (150% variance). Moves to Phase 3 without resolving divergence. Sprint planning fails.

Solution:

• Tolerance threshold: 20%: If variance > 20%, STOP and investigate
• Understand why:
  • Did Designer miss complexity?
  • Did Team misunderstand approach?
  • Underestimated technical risks?
• Revise plan: Simplify OR increase time scope
• Never ignore divergence: Symptom of deep misunderstanding

Check Definition of Done #5: “Estimates aligned (variance < 20%)“

4. Unidentified External Dependencies

Problem: Perfect plan but forgets module depends on external API not yet deployed, or data that doesn’t exist in database.

Solution:

• Dependency checklist:
  • External APIs (availability, SLA, auth)
  • Data sources (DB tables, schemas)
  • Internal services (other teams)
  • Third-party libraries (version, license)
• Validate BEFORE Phase 3: Identified blockers = pause until resolved
• Fallbacks: If dependency uncertain, prepare mock/stub

Check Definition of Done #6: “All external dependencies identified”

5. Product Owner Absent from Critical Transfer

Problem: PO not present. Team validates technical plan that doesn’t really meet business needs.

Solution:

• PO present minimum 30 min: At start (presentation) and end (validation)
• Explicit business validation: PO confirms “This plan meets the story”
• Fast business decisions: If business question arises, PO decides on the spot

Check Definition of Done #7: “Designer AND Product Owner approve”

Relationship with Agile - Details

Precise Mapping of Agile Concepts → DC²

Typical 2-Week Sprint Integration

Sprint N-1 (Preparation):

• PO presents User Stories at Product Backlog Refinement
• Designer performs Phase 1 for prioritized stories (architecture)

Sprint N - Day 1 (Monday):

• Morning: Phase 2A (LLM generates tactical plans—30-40 min)
• Afternoon: Team reads plans, prepares questions (30-60 min each)

Sprint N - Day 2 (Tuesday):

• Morning: Phase 2B (Critical Transfer—90-120 min) = Technical Sprint Planning
• Afternoon: Phase 3 (Test Generation—1.5h)
• End of day: Final estimates, commitment

Sprint N - Days 3-10:

• Phases 4-5: Implementation + Refactoring
• Daily standup as usual
• Phase 6 (optional) if component is critical

Sprint N - Final Days:

• PO Demo
• Retrospective

Agile Tools Compatibility

Jira / Azure DevOps:

• User Story stays in backlog
• Phase 2 Components = Story Sub-tasks
• Tactical Plan = attached as document
• Phase 3 Tests = Test Cases linked to story

Jira Example:

User Story: PROJ-123 "Display prediction confidence"
├─ Sub-task: PROJ-124 "Implement confidence_calculator"
├─ Sub-task: PROJ-125 "Implement confidence_explainer"
└─ Sub-task: PROJ-126 "Implement confidence_presenter"

Attachments:
├─ Tactical_Plan_PROJ-123.md (Phase 2)
├─ Architecture_Decision_Confidence.md (Phase 1)
└─ Tests_PROJ-123.py (Phase 3)