Backlog
Kept as an explicit prioritized work list, but connected to Project Truth, risk, discovery and architecture decisions.
Methodology · From need to evidence
An engineering methodology for working with AI without losing judgment, control or traceability.
DCP Flow combines adapted Scrum practices, Solution Discovery, architecture, AI agents, Quality Gates, Evidence and Human Gates. It does not copy Scrum; it reuses useful components inside a broader system focused on verifiable decisions.
Scrum → DCP Flow
What we take from Scrum and how we reuse it
DCP Flow preserves iteration, backlog, prioritization, sprints, review and continuous improvement. It reduces ceremonies and rigid roles when they add little value and reframes the sprint as a contract for a verifiable outcome.
Sprint
Not only a time box: a bounded commitment to one or more verifiable outcomes, expected evidence and explicit limits.
Sprint Planning
Reused as outcome preparation: scope, dependencies, risk, Golden Flows, involved agents and Definition of Done.
Daily / synchronization
A daily ceremony is not mandatory. Coordination is proportional to team and risk, especially with multiple agents or humans.
Review
Becomes Human Review supported by evidence: the result is checked against outcome, Golden Flows, Quality Gates and the real artifact.
Retrospective
Expanded into Lesson Learned: what worked, what failed, what stays local and what may evolve Standards, Blueprints, Skills or Gates.
Roles
Scrum roles are not copied by dogma. DCP Flow distinguishes Human Owner/Reviewer, Kai, Execution Agents and technical responsibility by context.
Increment
The increment must be demonstrable. Code, docs or config count as progress only with evidence proportional to risk.
Beyond Scrum
Principles that extend Scrum inside DCP Flow
Discovery before execution
Before BUILD, SaaS, OSS and components are investigated; coding is not the automatic first answer.
Architecture & Project Truth
Work does not start from isolated tickets: it starts from context, ADRs, Blueprint, repository truth and boundaries.
AI-native with governance
Kai and agents accelerate work, but technical capability does not equal operational authorization.
Quality Gates + Evidence
“Done” is not enough. Outcomes require checks, artifacts, browser/runtime evidence and Human Acceptance when applicable.
DCP Flow
The DCP Flow journey
Problem
Understand the need before choosing technology.
Capabilities
Define what the solution must be able to do.
Discovery
Compare SaaS, OSS, components and real alternatives.
Decision
IMPLEMENT, EXTEND or BUILD with evidence.
Architecture
Choose structure, stack, boundaries and risks.
Sprint
Turn the objective into verifiable outcomes.
Execution
Humans, Kai and agents work with shared context.
Quality Gate
Evidence determines whether progress is allowed.
Learning
Lessons can remain local or evolve DCP Flow.
Discovery Gate
Solution Discovery before BUILD
The first response is not to code. DCP Flow requires investigating what exists, testing candidates and measuring GAP before justifying custom development.
Adopt an existing solution.
Use an existing base and expand capabilities.
Build when evidence shows it is the best option.
Kai · Architecture context
Kai supports context, not replaces architecture
Kai can help read the project, connect prior decisions, analyze repositories and infrastructure, and prepare handoffs. Architecture remains a traceable DCP Flow decision and stays subject to Human Gates.
Evidence
Quality Gates: evidence before confidence
A change is not ready because an agent says it works. It is ready when sufficient evidence exists for the risk level and relevant Golden Flow.
01 → 03 → 06 → 12