Skip to content

Story points

Story points (SP) measure scope x uncertainty — not time. soloscrum uses a 1/2/3/5 scale. SP > 5 means the Issue must be split before /develop runs.

SPScopeUncertaintyCalibration (observed, not the unit)
11 file / 1 concernAll decisions known~30K-100K tokens, agent ~5-10 min
22-3 files / single skill area1 minor decision~100K-200K tokens, agent ~10-20 min
3Single subsystem cross-cut1-2 design decisions~200K-500K tokens, agent ~20-45 min
5Multi-subsystem cross-cutMultiple design decisions~500K-1M tokens, agent ~45 min-2h
>5(over-budget)(over-budget)Do not assign — split per issue-size and re-estimate

SP appears at two points in the lifecycle:

Issue SP is a size check. The PO uses it during /refine to decide whether the Issue is small enough to enter the lifecycle, or whether issue-size needs to fire suggest_split first. Issue SP is not stored — it is a decision input, not a record.

Subtask SP is the actual recorded value. Dev calculates it during /breakdown from the subtask’s AC and writes it to the tracker via soloscrum-tracker-{github|linear}-set-sp. This value is used for backlog planning and progress tracking.

Time anchors are deliberately excluded:

  • Model speed shifts release-to-release. Today’s “2 hours” becomes next month’s “20 minutes”.
  • Agents run in parallel, which warps wall-clock comparisons.
  • Human time and AI agent time do not map linearly.

Pinning SP to a clock unit made the scale unstable. The Calibration column exists for sanity-checking, not as input.

For both levels:

  1. Read AC / Goal to identify scope: how many subsystems / concerns are touched?
  2. Identify uncertainty: how many open design decisions remain after AC? Is anything novel?
  3. Map (scope, uncertainty) to the SP table. Both axes have to fit; pick the higher row when in doubt.
  4. If the result exceeds 5, the Issue is over-budget — split per issue-size and re-estimate.