Sprint closure

Table of Contents

Summary

In agile practice, closing an iteration combines the review — demonstrating what was actually delivered to stakeholders — and the retrospective — the team inspecting its own process and adapting it. Closure is what makes iterations comparable: each one ends with an honest account of what shipped and what was learned.

In ORE Studio, sprint closure is more than flipping the sprint to DONE: every story is explicitly resolved, the sprint's achievements are written down, release notes are generated when a release is cut, the retrospective captures what the sprint taught, the outreach (LinkedIn, Twitter/X, Discord) tells the world, and the sprint demo shows the outcomes working. Closure ends when the record is complete — only then does the next sprint's planning begin.

Detail

Ownership

Owned by System 3 (drives the sequence). System 2 resolves each story (DONE / ABANDONED / carried); System 4 weighs in on whether to cut a release.

The closure sequence

Closing and opening are separate PRs: one PR closes the sprint (carries, release notes, sprint DONE); a second PR opens the next sprint (scaffold, stories, version bump). Never combine them.

  1. Resolve every story. Every story in the sprint is DONE, ABANDONED, or carried to the product backlog (next step).
  2. Carry the unfinished work to the product backlog. Stories that did not make it move by file into the inbox, preserving their immutable :ID: so every existing id-link (sprint table, journals, other docs) keeps resolving:
    • An undecomposed story (folder holds only story.org) moves flat: git mv <story>/story.org doc/agile/product_backlog/inbox/<story_name>.org and the empty folder is removed.
    • A story with task files (a partial: STARTED / BLOCKED) moves as a whole folder, so its task history, Results, and PRs travel with it.
    • In the sprint's * Stories table the moved story's row is marked ABANDONED with the close date — the sprint records that it didn't make it; the live document now lives in the backlog.
    • Never copy a story into a new capture: that mints a new ID for the same work and severs traceability.
    • Re-run the backlog index regeneration so inbox.org lists the carried stories.
  3. Write the Achievements. Add a ** Achievements sub-heading inside * Status, after the Status table. Write 3–7 bullet points capturing what the sprint actually delivered — specific outcomes, not story titles. Clear the Now field to Nothing. at the same time. Achievements are only written at sprint close; the heading does not appear in in-flight sprints.
  4. Generate the release notes. Scaffold via compass add release_notes into the sprint folder (the file lives at the sprint root so the chart file: links resolve), then populate from the collected PR data and the closed tasks' * Result sections, and link the notes from the sprint's Status table and * Release Notes section.
  5. Cut the release (tag, build, publish artefacts) when the version warrants it. Not every sprint produces a release; many sprints land mid-version. See Compass for what the release tag means in terms of CMake major/minor.
  6. Do the outreach. Announce what shipped: a LinkedIn post, a Twitter/X post, and a Discord announcement. Outreach draws on the Achievements and the release notes; it happens whether or not a release was cut — sprints that land mid-version still have a story worth telling.
  7. Run the post-mortem. Fill the sprint's * Retrospective section — what went well, what hurt, what changed. Past sprints under doc/agile/versions/v0/sprint_*/ are the template.
  8. Create the sprint demo. The last step of closing a sprint: produce the demo showing the sprint's outcomes working — the user-visible proof behind the Achievements.
  9. Transition the sprint itself to DONE, set the End date, and update Last touched on the Status row; close the sprint's row in the version's sprint table. The opening of the next sprint is its own PR — see Open a new sprint.

Sprint closure ends when all the steps are complete; the next sprint's planning phase can then begin.

When the sprint is done

A sprint is done when every story is closed, the Retrospective is filled, and release notes are generated if applicable. (Story and task doneness are defined on their own pages: Stories, Tasks.)

See also

Emacs 29.1 (Org mode 9.6.6)