Core Principle

Reducing batch size is the single highest-leverage practice in software delivery. Smaller batches produce faster feedback, lower risk, shorter cycle times, and higher quality. This is provable via queuing theory (Reinertsen) and validated empirically by DORA research. DORA lists “working in small batches” as a core capability that predicts both software delivery and organizational performance.

Why This Matters

Most organizations default to large batches: weekly sprints, feature branches that live for days or weeks, release trains, staged deployments. Each of these introduces invisible queues. Reinertsen proved mathematically that these queues are the dominant source of delay and variability in product development. In software, the queues are: open PRs waiting for review, branches waiting for merge, changes waiting for the next deploy window, bugs waiting for triage.

Evidence/Examples

  • DORA research: working in small batches predicts improved delivery performance dora.dev/capabilities/working-in-small-batches/
  • The INVEST principle for batch decomposition: Independent, Negotiable, Valuable, Estimable, Small (hours to days), Testable
  • Traditional phased approaches required weeks/months for feedback; small-batch continuous delivery enables feedback “from development through test and operations into production in a matter of minutes”
  • DORA 2025: “working in small batches acts as a critical countermeasure” to delivery instability caused by AI adoption, preventing increased velocity from becoming chaos

Implications

  • Feature flags and dark launching allow deploying incomplete features safely, decoupling deployment from release
  • Code review should happen on small diffs (easy to review, fast to merge), not large PRs (hard to review, slow to merge, higher defect rate)
  • The “right size” for a batch is: deployable within hours, reviewable in one sitting, testable in isolation

Questions

  • Is there empirical data on the relationship between PR size and defect rate?
  • How do small batches interact with architectural decisions that require coordinated changes across multiple services?

Sources