GktuOktay Project Planning & Task Breakdown Skill
Overview
This skill focuses on taking a high-level requirement or abstract idea and transforming it into a structured, actionable, and prioritized implementation plan. It covers task decomposition, dependency mapping, risk identification, and structured outputs for engineering execution.
Phase 1: Requirements Analysis
Before breaking down tasks, establish absolute clarity on what needs to be built.
- Objective Statement: What is the primary goal of this project?
- Scope Boundaries: Explicitly define what is IN scope and what is OUT of scope.
- Success Criteria: How will we know this project is completed successfully? (e.g., Performance metrics, user acceptance tests).
Phase 2: Task Decomposition (The Hierarchy)
Break down the work into progressively smaller, manageable units.
- Epics (High-Level Features): Major functional areas (e.g., "User Authentication System").
- Stories (User-Centric Work): Specific functionality delivering value (e.g., "As a user, I can log in with Google").
- Tasks (Technical Implementation): Engineering steps to achieve a story (e.g., "Set up OAuth2 endpoints", "Create Login UI component").
- Subtasks (Checklist Items): Micro-steps (e.g., "Add Google logo asset", "Write unit tests for token validation").
Rule of Thumb: A Task should represent work that takes a single engineer 1-3 days to complete. If it takes longer, it should be broken down further.
Phase 3: Dependency Mapping
Identify the order of operations to prevent blockers.
- Finish-to-Start (FS): Task B cannot start until Task A finishes. (Most common in software).
- Parallel Workstreams: Identify which tasks can be developed concurrently by different team members (e.g., Frontend UI can be built with mock data while Backend API is being developed).
Example Mapping:
- Database Schema (Blocks ->) Backend API
- Backend API (Blocks ->) Frontend Integration
- UI Mockups (Blocks ->) Frontend Layout
Phase 4: Risk Identification & Mitigation
Analyze potential failure points before coding begins.
- Technical Risks: Unproven technologies, third-party API rate limits, complex migrations.
- Scope Risks: Vague requirements, feature creep.
- Mitigation Strategy: For each high-risk item, define a mitigation (e.g., "Create a Spike/PoC for the third-party API integration before committing to the full architecture").
Phase 5: Prioritization Frameworks
When scope exceeds time/resources, use prioritization.
MoSCoW Method
- Must Have: Non-negotiable for the MVP.
- Should Have: Important, but not strictly necessary for launch.
- Could Have: Nice to have if time permits.
- Won't Have: Explicitly excluded from this phase.
RICE Scoring (For Feature Selection)
- Reach: How many users does this affect?
- Impact: How much does it improve the experience?
- Confidence: How sure are we of our estimates?
- Effort: How long will it take? (Score = Reach * Impact * Confidence / Effort)
Output Template: Implementation Plan
When generating a plan, use this structured artifact format:
# Implementation Plan: [Project Name]
## 1. Executive Summary
- **Goal**: Brief description.
- **Out of Scope**: What we are explicitly NOT doing.
## 2. Technical Architecture/Approach
- Brief overview of technologies, frameworks, and architecture decisions.
## 3. Milestones & Task Breakdown
### Milestone 1: Foundation & Data Layer (Must Have)
*Goal: Set up database schemas and core abstractions.*
- [ ] **Task 1.1**: Define User schema (Dependency: None)
- [ ] **Task 1.2**: Setup DB migrations (Dependency: 1.1)
### Milestone 2: Core API & Logic (Must Have)
*Goal: Implement business logic and endpoints.*
- [ ] **Task 2.1**: Implement auth endpoints (Dependency: 1.2)
- [ ] **Task 2.2**: Write API integration tests (Dependency: 2.1)
### Milestone 3: Frontend & Integration (Should Have)
*Goal: Connect UI to the backend.*
- [ ] **Task 3.1**: Build login form components (Dependency: None - use mocks)
- [ ] **Task 3.2**: Connect login form to API (Dependency: 2.1, 3.1)
## 4. Identified Risks & Mitigations
- **Risk**: API Rate limits from provider.
- **Mitigation**: Implement caching layer early in Milestone 2.
Conclusion
A good plan is not static; it is a living document. The goal of planning is to remove ambiguity, identify critical paths, and align engineering execution with product goals.