obsidian-kanban-implementation-planning

name	obsidian-kanban-implementation-planning
description	Use for effective project planning with a top-level implementation plan and feature-level Kanban tracking using Obsidian data cards. Helps define scope, sequence delivery, manage dependencies, and drive execution with clear acceptance checks.
argument-hint	What project are you planning, and what features should be tracked on the Kanban board?

Implementation Planning With Obsidian Kanban Cards

What This Skill Produces

• A structured overall implementation plan that aligns goals, phases, risks, and milestones.
• A feature-level Kanban workflow backed by Obsidian data cards.
• Clear movement rules, review cadence, and completion criteria from idea to done.

When to Use

• Starting a new product or major feature initiative.
• Replanning a project that has unclear sequencing or ownership.
• Coordinating multiple features with dependencies and staged delivery.
• Moving from ad-hoc task lists to a stable execution system.

Default Planning Model

• Planning layer: one implementation plan document for vision, architecture, phases, dependencies, and release path.
• Execution layer: Kanban columns with one Obsidian data card per feature.
• Default Kanban columns: Backlog, Ready, In Progress, In Review, Blocked, Done.
• Cadence: board review every Monday.
• WIP policy: no fixed global limit; adjust based on team capacity and flow health.
• Data-card schema: required frontmatter fields for every active feature card.

Workflow

1. Define outcomes and planning horizon.
2. Build the overall implementation plan.
3. Define card model for Obsidian feature tracking.
4. Build and initialize Kanban board.
5. Prioritize and sequence feature cards.
6. Execute with pull-based Kanban flow.
7. Review metrics and adjust plan.
8. Close features and capture learnings.

Detailed Procedure

1) Define outcomes and planning horizon

• Document business/user outcomes and success signals.
• Choose planning horizon (for example, current release or quarter).
• Identify hard constraints: staffing, time, compliance, external dependencies.

Decision points:

• If outcomes are ambiguous, pause execution setup and refine goals first.
• If scope is too broad for horizon, split into incremental releases.

Completion checks:

• Outcomes are measurable.
• Constraints are explicit and accepted by stakeholders.

2) Build the overall implementation plan

• Capture architecture direction, major workstreams, and phase ordering.
• Map cross-feature dependencies and critical path risks.
• Define milestone exit criteria and delivery checkpoints.

Decision points:

• If dependency risk is high, schedule enabling work before feature work.
• If unknowns are significant, add discovery spikes as planned cards.

Completion checks:

• Plan has phases, dependencies, owners, and milestone gates.
• Every planned phase has clear entry and exit criteria.

3) Define card model for Obsidian feature tracking

• Create a standard data-card schema for all features.
• Include fields for scope, owner, priority, status, dependencies, risk, and acceptance criteria.
• Ensure each card links back to the implementation plan phase and milestone.

Required frontmatter fields:

• id
• title
• status
• owner
• priority
• phase
• milestone
• dependencies
• risk_level
• acceptance_criteria
• last_updated

Decision points:

• If feature scope exceeds one card, split into smaller vertical slices.
• If ownership is unclear, do not move card into active work.

Completion checks:

• Card schema is standardized and documented.
• All active features have complete required fields.
• Card status always maps to one of the board columns.

4) Build and initialize Kanban board

• Define board columns as Backlog, Ready, In Progress, In Review, Blocked, Done.
• Keep WIP policy adaptive instead of fixed; update guidance based on current capacity and flow.
• Add policy notes for card movement and blocking behavior.

Decision points:

• If cards age too long in a column, tighten WIP or split cards.
• If blocking is frequent, add a visible blocked state and escalation rule.

Completion checks:

• Board states are unambiguous.
• Card movement rules are visible and consistently applied.

5) Prioritize and sequence feature cards

• Rank cards by outcome impact, urgency, and dependency readiness.
• Pull only ready cards into active work.
• Sequence high-risk dependency items early to reduce downstream delay.

Decision points:

• If two cards compete, prioritize the one that unlocks more follow-on work.
• If a card lacks acceptance criteria, keep it in backlog refinement.

Completion checks:

• Next set of cards is dependency-safe and value-focused.
• Active queue respects WIP limits.

6) Execute with pull-based Kanban flow

• Move cards based on completion evidence, not calendar pressure.
• Keep card updates current in Obsidian (status, notes, blockers, owner).
• Escalate blocked cards quickly with a concrete unblock action.

Decision points:

• If card scope grows mid-flight, split and return overflow to backlog.
• If blocked beyond agreed threshold, trigger plan-level risk mitigation.

Completion checks:

• Card states reflect real progress.
• Blockers have owners and deadlines.

7) Review metrics and adjust plan

• Track flow metrics such as lead time, cycle time, blocked time, and throughput.
• Compare observed flow against milestone targets.
• Adjust sequencing, WIP limits, or card slicing rules as needed.
• Run formal board review every Monday and log resulting actions.

Decision points:

• If cycle time trends upward, reduce parallel work and shrink card size.
• If throughput is unstable, rebalance ownership or reduce in-flight commitments.

Completion checks:

• Improvement actions are logged and applied.
• Plan remains realistic against current flow data.
• Monday review decisions are reflected on cards and the implementation plan.

8) Close features and capture learnings

• Verify acceptance criteria are met before marking done.
• Record implementation notes and follow-up opportunities in each card.
• Update plan status and milestone readiness based on completed cards.

Completion checks:

• Done cards contain verification evidence.
• Lessons learned are captured for future planning cycles.

Definition Of Done

• Overall implementation plan and Kanban board stay aligned.
• Every active feature is represented by a complete Obsidian data card.
• Flow policies and blocker escalation are followed, with capacity tuned from observed flow.
• Feature completion is acceptance-based and evidence-backed.
• Planning improvements are captured and applied in the next cycle.