Translation
Translated from the Spanish source, which is the normative text. Status: draft pending human review. Differences are resolved in the Spanish text.
description: How SCAFFOLD organises planned work: work list, items and batches, states, ready and done, cadence, events, estimation and capacity, with correspondences and differences with Scrum and Kanban.¶
SCAFFOLD — Work and cadence¶
In brief. Planned work is recorded as work items in a list ordered by people. An item is what is planned; the batch is the unit that executes it. Each item passes through six states, goes into progress when it meets a definition of ready and is considered done with a definition of done and the acceptance of a person. The project chooses fixed-length cycles or continuous flow with a work-in-progress limit. The rule (R-024) requires declaring the cadence and how often a review of finished work and a process improvement session are held; planning and the brief sync are suggested practices. The page explains; the rule is in R-021 to R-024 and R-031.
Certainty level (MILPA): the rules cited are accepted rules of SCAFFOLD 0.1; the examples of definition of ready and definition of done are illustrative; the table of correspondences is an editorial reading of public sources, not an equivalence or an endorsement by their authors.
Who it is for and first step¶
For whoever orders and distributes the work of a project with people, AI assistants or both. First step: create the work list with a first item that has verifiable acceptance criteria, and declare the cadence. General context in Project cycle.
Work list, items and batches¶
The work list is the ordered set of the project's work items (R-021). A work item has a stable identifier that is not reused, type, goal, acceptance criteria, responsible person, state, dependencies and a parent item or none.
The item and the batch are different things:
| Work item | Work batch | |
|---|---|---|
| Answers the question | What is wanted and why? | How and with whom is it executed? |
| Defined by | Product owner | Batch owner |
| Contains | Acceptance criteria, parent, dependencies | Zones, assistants, interval, result, cost or "unknown" |
| Relationship | May be executed in one or more batches | A feature or fix batch cites at least one item |
| Rule | R-021 | R-009 |
An investigation or restructuring batch may be opened without an item if it declares its reason. The templates page shows the fields of each format.
Hierarchy¶
An item may have a parent. An initiative is an item of type iniciativa (initiative) that
groups child items through the parent item field. The other types are feature,
fix, restructuring, investigation or another the project declares. The hierarchy runs from the
initiative to the item. The rule does not fix how many levels it admits or when an
initiative is considered done; each project declares those rules.
Fictional example: Ana, who maintains an online shop with two assistants, creates the initiative "exports" and, within it, the item TIE-12, "export orders to CSV", with the acceptance criterion "the file contains all the columns of the orders contract and downloads in under a minute with 1000 test orders". TIE-12 is executed in a feature batch.
Item states¶
The states form a scheme of their own for items: they are not those of a batch, a note or a requirement. As with the method's other classification values, the state values stay in Spanish; the English gloss is in the table.
| State | Meaning | Moves to the next when |
|---|---|---|
propuesto (proposed) |
Someone raised it (a person or an assistant); it is not yet ordered or accepted as work. | The product owner orders it and it meets the definition of ready, or discards it. |
listo (ready) |
Meets the definition of ready and awaits its turn. | A responsible person assigns it and starts. |
en_curso (in progress) |
Being executed in one or more batches. | Its batches close and review and acceptance are requested. |
en_revisión (in review) |
Acceptance criteria and the definition of done are checked. | A person with the corresponding role accepts it, or it returns to en_curso. |
terminado (done) |
Checked and accepted by a person. | Final state. |
descartado (discarded) |
It was decided not to do it, with a reason. | Final state. |
An assistant may propose items, criteria and order; ordering, accepting and discarding are decisions of a person with the declared role, and the decision is recorded (R-022). A closed batch does not make the item done: it records that the work ended, not that it was accepted.
Definition of ready and definition of done¶
The project declares both, with a version (R-023). Illustrative examples:
- Definition of ready (example). It has a goal and verifiable acceptance criteria, a responsible person, known dependencies and, if it touches data, their classification.
- Definition of done (example). Acceptance criteria checked; the repository's integration checks run (R-010); integration request reviewed by a person; pending notes closed; acceptance recorded.
The rule requires the definition of done to include the integration checks and that no item be marked done without a person's acceptance. The rest of the content of the definitions is decided by each project. Residual risk: a weak definition lets incomplete work through.
Cadence: cycles or continuous flow¶
The project declares one of two cadences (R-024):
- Fixed-length cycles. A group of items is planned for a period of declared length; at the end, what is done is reviewed. The project chooses the length.
- Continuous flow with a work-in-progress limit. Items enter when there is room; the
project declares a limit of items per state (for example
en_cursoanden_revisión), per person or per crew. With the limit full, no other item is started until one moves on or is done.
With either cadence the project declares how often it reviews finished work and holds the process improvement session, and holds them with date, participants and agreements recorded (R-024). As a cadence alternative, Shape Up describes six-week cycles and a prior bet on which work goes in; see the table of correspondences.
Events¶
SCAFFOLD 0.1 requires declaring the cadence and how often the review and the improvement session are held (R-024). The following four events are one way to meet what the rule asks, with editorial names and times; planning and the brief sync are suggested practices, not required (the suggested times are Hypothesis until measured).
| Event | Purpose | What it includes | Output |
|---|---|---|---|
| Planning | Decide which items go in and who carries them. | Review the list order, the definition of ready and capacity (see below). | Items assigned to a responsible person. |
| Brief sync | Detect blockers and collisions in the work in progress. | Read the assistants' handoff notes and open batches; review shared zones and turns. | Blockers with an owner; notes taken or returned. |
| Review of finished work | Accept or reject items and see what was delivered. | Check the criteria and definition of done of each item. | Recorded acceptances; items returned. |
| Process improvement | Change how work is done. | Review what worked and what did not, with measured data where it exists. | Agreements with date and participants; each agreement, where possible, turned into a work item. |
The brief sync includes reading what the assistants left written, because an assistant does not retain memory of what was not left in a note or a batch. That statement describes the design reason; its effect has not been measured.
Estimate and measured data¶
An estimate is a prior calculation; measured data is what was observed during execution. The rule requires recording them separately (R-031) and, in batches, recording cost as data or as "unknown", never as a disguised estimate (R-009). Fictional example: TIE-12 was estimated at two days of Ana's time; the batch measured seven hours of Ana in review and an assistant consumption that the project did not record, so it appears as "unknown".
Capacity of people and of agents¶
The capacity of people is measured in available time. That of agents is limited by their budget and by the human review their results require. Every item in progress has a responsible person even if an agent executes it (R-031).
Practical consequence: adding assistants can increase the work awaiting review. If
human review becomes the bottleneck, the work-in-progress limit or the number of
items in en_revisión makes it visible. Whether this happens in a specific project is a
hypothesis until measured; the record itself flags it as a residual risk.
Correspondences with Scrum, Kanban and Shape Up¶
The table compares; it does not claim equivalence. SCAFFOLD adopts what its rule says, not the rules of these frameworks. The sources are primary and are cited by section or topic; editions change and the comparison must be repeated against the current edition.
| Idea in SCAFFOLD | Scrum (The 2020 Scrum Guide) | Kanban (The Kanban Guide, May 2025) | Shape Up | Main difference |
|---|---|---|---|---|
| Work list ordered by a person responsible for the product | "Scrum Artifacts": the Product Backlog; in "Scrum Team", the Product Owner orders it. | The guide describes a board with work items that flow; the order is not detailed here (not verified). | "The Betting Table": a bet is placed on which work to do; there is no single continuous list. | SCAFFOLD requires that ordering and discarding be decided by a person with a declared role and that the assistant only propose (R-022). |
| Work item with acceptance criteria | Product Backlog items; no mandatory acceptance criteria in the guide (to be verified). | Work items that flow. | "Shaped" projects with boundaries. | SCAFFOLD requires verifiable criteria and distinguishes the item from the batch. |
| Definition of done | "Scrum Artifacts": the Definition of Done is the commitment for the Increment. | Not verified here. | Does not apply directly. | In SCAFFOLD the definition includes the integration checks and the acceptance of a person (R-023). |
| Fixed-length cycles | "Scrum Events": the Sprint, of fixed length with a maximum stated in the guide. | Does not require cycles. | "Bets, Not Backlogs": six-week cycles as an alternative. | SCAFFOLD lets the project choose cycles or continuous flow and does not fix the length. |
| Continuous flow with a work-in-progress limit | Not part of Scrum as the guide defines it. | Work-in-progress limits and flow: central theme of the guide. | Does not apply. | SCAFFOLD requires declaring the limit if the cadence is continuous flow (R-024). |
| Planning, brief sync, review, improvement | "Scrum Events": Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective. | The guide defines its own practices; not verified one by one here. | Own alternatives. | SCAFFOLD describes four events as one way to meet R-024, which requires declaring cadence, review and improvement; names and frequency are the project's. |
| Appetite or maximum time | The Sprint length bounds the work. | Work-in-progress limits bound the quantity. | "Set Boundaries": the appetite (how much time one is willing to invest) is a prior decision. | SCAFFOLD does not include appetite; it could be used as an ordering criterion by project decision. |
| People and agents | "Scrum Team": people with defined responsibilities; the guide does not distinguish AI agents. | Same: does not distinguish AI agents. | Same. | SCAFFOLD distinguishes capacity and responsibility of agents (R-030, R-031); an agent holds no role. |
Sources:
- The 2020 Scrum Guide, sections "Scrum Team", "Scrum Events" and "Scrum Artifacts" (accessed 14 Oct 2026).
- The Kanban Guide: a May 2025 edition exists, and it is the one cited (accessed 14 Oct 2026). Only the topic is cited (work-in-progress limits and flow); section titles have not been verified.
- Shape Up, chapters "Set Boundaries", "The Betting Table" and "Bets, Not Backlogs" (accessed 14 Oct 2026).
The access date shows when the source was opened; it does not verify the table cells. Cells marked "not verified" or "to be verified" are Hypothesis. To promote them it suffices for a person to read the source section in the current edition, note the exact citation and date of consultation, and correct the cell. This table does not claim that SCAFFOLD is a version of Scrum or of Kanban, or that the authors of those frameworks endorse it.
Limits¶
- The page adds no requirements: R-021 to R-024 and R-031 are the ones that count.
- The states, events and examples of ready and done are presentations; a project can meet the rule with other names.
- Nothing is promised about less rework, more speed or greater security. Any improvement must be measured before and after (R-032).
- A finished item does not guarantee quality; a person can accept without reviewing (residual risk of R-022).
Further reading: Project cycle, Crews, Templates. Back to SCAFFOLD.