# Project Sprint A structured workflow for executing a scoped unit of business work — a client project, a renovation, a product launch, an operational improvement. The sprint ensures nothing falls through the cracks: every deliverable is checked against what was agreed, every deviation is surfaced, and every project produces a structured record and accumulated learnings. ## Adaptive Tiers Not every project needs the same level of structure. Select the tier based on the project's complexity, risk, and duration. | Tier | When to use | Phases | |------|-------------|--------| | Quick | Simple, low-risk work: fix a leak, send an invoice, single deliverable with no dependencies | Scope, Execute, Done | | Standard | Medium complexity: multi-step work with some dependencies and a client-facing deliverable | Plan, Execute, Verify, Debrief | | Full | Complex projects: multi-week, multiple dependencies, significant risk, multiple stakeholders | Plan, Challenge Premise, Lock Execution, Execute, Verify, Plan Conformity, Debrief, Deliverable Review, Learnings | When the user's intent is ambiguous, suggest a tier and let them adjust. If a Quick sprint reveals unexpected complexity mid-execution, offer to upgrade to Standard. --- ## Quick Tier ### Scope Understand what needs doing. Confirm the deliverable, the deadline (if any), and who it's for. Create the parent Task with `[PROJECT:START]` and a single child task for the work. ### Execute Do the work. Track progress via task notes. Check `work-ready` if there are any dependencies. Mark the child task complete when done. ### Done Confirm the deliverable is complete. Mark the parent Task complete with `[PROJECT:COMPLETE]`. If there's a follow-up, create a new task for it. --- ## Standard Tier ### Plan Understand the project scope: what are the deliverables, who are they for, what's the deadline, what are the dependencies. Create the parent Task and child tasks for each work item. Link dependencies via `BLOCKS` and related entities via `AFFECTS`. Check for prior learnings: call `memory-search` with a description of the project to surface relevant learnings from past similar work. If learnings exist, factor them into the plan — adjust timelines, flag known risks, apply lessons learned. When the project has more than one interested party, map them with `references/stakeholder-map.md`. When many tasks are ready and dependency order does not settle the sequence, order them with `references/prioritization.md`. Load either via `plugin-read`. ### Execute Work through the child tasks in dependency order. Before starting each task, check `work-ready` to confirm no blockers or AFFECTS conflicts. Append progress notes as work progresses. If a blocker is discovered mid-execution, create a new child task for it and link via `BLOCKS`. Record phase transitions: `[PROJECT:PHASE] Execute — starting {task name}`. ### Verify Walk through each deliverable against the acceptance criteria agreed in the Plan phase. For each deliverable: - Is it complete? - Does it meet the agreed standard? - Are there any outstanding items? Use domain-appropriate verification (see Domain Verification below). Flag any deliverable that was promised but not delivered, or delivered differently than agreed. ### Debrief Produce a structured record: - **What was done:** Each deliverable and its outcome - **What changed:** Any deviations from the original plan and why - **What's next:** Immediate follow-up actions, if any - **Known limitations:** Anything intentionally deferred or incomplete Mark the parent Task complete with `[PROJECT:COMPLETE]`. --- ## Full Tier ### Plan Same as Standard Plan, but more thorough: map all stakeholders (use `references/stakeholder-map.md`), identify risks, estimate timeline for each work item, and define acceptance criteria for every deliverable. Order ready work with `references/prioritization.md` when the sequence is not obvious. ### Challenge Premise Before locking in the execution plan, challenge the scope: - Is this the right work to do right now? Could a different framing yield a better outcome? - What would happen if this project didn't happen? Is the pain real or hypothetical? - Are we solving the root cause or a symptom? - Is the scope right-sized? Too ambitious for the timeline? Too conservative for the opportunity? Surface any concerns and resolve them before proceeding. Run a pre-mortem to surface what could go wrong before the plan is locked: load `references/risk-premortem.md` via `plugin-read`. Mitigations identified here change the locked task list, so run it before Lock Execution. ### Lock Execution Finalise the execution plan: confirm the task list, dependency order, timeline, resource requirements, and acceptance criteria. This is the agreement — Phase 6 (Plan Conformity) will check the outcome against this. Record the locked plan in the parent Task notes: `[PROJECT:PHASE] Execution locked — {n} tasks, estimated {timeline}`. ### Execute Same as Standard Execute, with additional discipline: - At each session start, report project health (RAG signal from the PLUGIN.md) - Surface risks proactively — if a task is trending overdue, flag it before it becomes critical - When a blocker is discovered, assess its impact on the overall timeline ### Verify Same as Standard Verify, plus: - Verify graph state — correct entities created or modified, relationships intact - Verify communication log — messages sent, confirmations received (if applicable) - Run domain-appropriate verification ### Plan Conformity Compare every item in the locked execution plan against what was actually delivered. Every plan item must appear in exactly one category: - **Implemented as planned** — delivered as agreed, with evidence - **Deviated** — delivered differently than planned. State what changed and why. - **Omitted** — not delivered. State why it was dropped or deferred. - **Added** — delivered but not in the original plan. State why it was necessary. Silent omissions — items that were in the plan but neither delivered nor flagged — are the failure mode this phase exists to prevent. If deviations or omissions are found, present them for acknowledgement before proceeding. ### Debrief Same as Standard Debrief, plus: - **Change log:** For every deliverable, what was done, why, and what it means - **Dependency resolution:** Were all blockers resolved? Any still outstanding? - **Completion checklist:** Every requirement from the plan with pass/fail status ### Deliverable Review Review each deliverable against the original brief (not the execution plan — the brief that initiated the project). Check for completeness, accuracy, and client-readiness. Flag anything that was promised in the brief but not delivered, or delivered differently. ### Learnings Extract operational knowledge from the project. Load `references/retrospective.md` via `plugin-read` and follow that process. This produces persistent learnings that inform future projects. --- ## Domain Verification The verification phase should feel relevant to the business domain. Use the `businessType` property on the `LocalBusiness` node to select appropriate verification prompts. If no businessType is set, use the general prompts. ### Trades (plumbing, electrical, building, renovation) - Has the work been physically completed to standard? - Are all materials accounted for? - Has the client inspected and approved? - Are there any snagging items? - Is the site left clean and safe? - Has the warranty or guarantee period been communicated? ### Estate Agency (property sales, lettings, management) - Are all required documents complete and accurate? (EPC, floor plan, particulars, contracts) - Are photographs professional and current? - Has the listing been posted to all agreed portals? - Have all parties been notified of progress? - Are compliance requirements satisfied? (anti-money laundering, right to rent) - Is the file complete for audit? ### Professional Services (consulting, accounting, legal, design) - Has the deliverable been reviewed against the statement of work? - Has the client signed off or provided written acceptance? - Are all project files organised and accessible? - Has the final invoice been issued? - Are intellectual property and confidentiality obligations met? - Have handover notes been prepared for ongoing work? ### General (no specific businessType or unknown) - Is each deliverable complete against its acceptance criteria? - Has the recipient confirmed receipt and satisfaction? - Are there any outstanding actions or follow-ups? - Is the project file complete — communications, documents, decisions recorded?