Delivery standards: when work is Ready and Done
Delivery & Acceptance Standards.
This practice defines readiness to build, acceptance checks, verification, and release criteria. It keeps the completion decision tied to evidence.
Definition of Ready
A task is Ready when its purpose, scope, expected behavior, acceptance criteria, and significant dependencies are clear enough for implementation to begin.
Definition of Done
A task is Done when its acceptance criteria have passed, the result has been verified, evidence is recorded, and the authoritative task documentation is current.
Deployment, public accessibility, approval, and submission remain separate milestones when applicable. If one is part of a task’s acceptance criteria, that criterion still needs to pass before the task is Done.
The approach uses the existing specifications and task records. It does not require new mandatory fields or additional protocols.
Barnaby examples: clear requirements and acceptance checks
From a request to a testable contract.
The requirement “don’t add duplicates” becomes explicit behavior: normalize an item name, retrieve candidates, distinguish active matches from purchased records, and create only when absent. An unmatched update asks before creating an item.
I used the specification to separate local AI intent extraction from regular Notion writes, define pending confirmation state, and capture acceptance cases. A confirmation test recovered stored item and quantity and reached the duplicate checker; final persistence and full routing regression remain unverified.
A small next feature: mark a dinner as eaten
The published dinner-feature draft states the problem, user story, one-dinner scope, acceptance criteria, technical questions, and exclusions. Unknown or ambiguous names must not trigger an unintended update, and a failed Notion write must not produce a success reply.
The unresolved status mapping, confirmation behavior, and duplicate-name handling show what needs clarification before implementation. The draft illustrates preparing work for Ready; it does not prove readiness or that the dinner feature is Done.
Read the short dinner-feature specification ↗
Before and after the evidence review
Before: a cleanup branch appeared to execute, which could be summarized too broadly as “confirmation works.” After: the register records that component observation separately from the live-message, persisted-write, cleanup, and retry cases still needing evidence.
The cancellation phrase “no don’t add it” exposed a brittle rule. I documented the defect and regression cases rather than treating a proposed regex change as a verified fix.
Inspect Barnaby’s specification, diagram, and test register ↗
Project context: authoritative records and session handoffs
Project Context & Handoff.
This complementary practice defines where current requirements, decisions, task status, and evidence belong, and how work transfers between AI agents or development sessions. A project specification holds requirements and decisions; the authoritative task records its current status, remaining checks, and completion evidence. Approved deliverables are identified by their final linked version.
A useful handoff carries the current sources, scope, decisions, observed results, unresolved risks, and exact next action. The receiving session retrieves or is given that context explicitly; it does not assume other conversations are synchronized.
The Notion development board separates initiatives and records task, stage, priority, sprint, acceptance outcome, source document, evidence, and review date. It distinguishes Backlog, Ready, In Progress, Blocked, Review / Test, and Done.
A specification explains intended behavior; a task describes the next bounded increment; the evidence note explains what actually happened. A task being present on a board is not completion evidence.
Sanitized representative work item
Task: verify grocery confirm/cancel paths. Stage: Review / Test. Acceptance: yes/no variants, saved-state cleanup, duplicate/reactivation outcomes, and normal command routing behave correctly end to end. Evidence: node-level results exist; full regression is incomplete.
This is a recreated text example from the maintained records, not a screenshot of the private board. The board coordinates personal work; it is not evidence of managing a scaled engineering organization.
What I have learned and what I plan to improve
Documentation supports continuity; reconciliation keeps it credible.
I can return to recorded decisions and work states across sessions instead of relying only on conversational memory. That is a qualitative working observation, not a measured speed improvement.
- Separate conversations can carry conflicting assumptions. Supply the current reference and reconcile before integrating changes.
- AI-written specifications and status reports can overstate implementation. Inspect the result and preserve uncertainty.
- Notion is a reference, not proof that a test passed. Keep expected behavior separate from observed behavior.
- This is AI-assisted personal product work, not an autonomous multi-agent platform or a production orchestration system.
Next: apply the Ready/Done standards and context handoff to a bounded increment, then inspect the result against its acceptance criteria. A Markdown specification is available beside the hosted artifacts; a GitHub/code-context pilot remains future work. Keep the process focused on useful delivery, with only the documentation needed to support it.
Future measurement: time to value
Measure useful progress when measurement is warranted.
Time to value is a future measurement principle, not a new tracking obligation. Three potential measures could help evaluate the method:
- Time from an initial request to Ready.
- Rework caused by unclear requirements.
- Time from Ready to verified delivery.
These measures are not being tracked by this update. No new metrics, mandatory fields, or additional protocols are introduced, and no time savings are claimed.