Sprints and commitments

Backlog grooming and Sprint planning

On the Backlog’s GroomingCadence, the Product Owner opens the Project Backlog view, ranks Issues via BacklogRank, sets Estimate on IssueTypes.RequiresEstimate = true rows, assigns ParentEpic and tentative FixVersion. For Sprint planning, the Scrum Master opens a Future Sprints row (with Goal, StartDate, EndDate, Board, CapacityPoints defaulted from TeamVelocity.TrailingThreeAverage), pulls top-ranked Backlog Issues into the Sprint by setting Issues.Sprint to the Future Sprint, until the committed estimate matches capacity.

Sprint start

Scrum Master flips the Sprint Status: Future → Active. The sprint-start-snapshot workflow fires via the configured record event, walks every Issues row attached to the Sprint, bulk-inserts one SprintCommitments row per Issue freezing the CommittedEstimate, CommittedStatus, and CommittedAssignee snapshot at sprint-start, stamps Sprints.StartedAt, and emails the kickoff digest with committed scope to the Scrum Master + Project Lead. The Sprint board becomes the squad’s daily surface.

Sprint close, retro, rollover

On the Sprint EndDate the Scrum Master flips Status: Active → Closed. The sprint-end-rollover workflow fires, finds every Issue in the closing Sprint with Status NOT IN (Done, Cancelled), and first freezes SprintOutcomes for all committed, added and removed issues. It then applies Projects.IssueRolloverRule: either nulls Issues.Sprint (back to Backlog) or sets it to the next Future Sprint. The velocity-recompute job upserts the Sprint’s TeamVelocity row with CommittedPoints (from SprintCommitments), CompletedPoints (from immutable SprintOutcomes recorded before rollover, using the agreed estimate unit), and Carryover; refreshes the trailing-3 average. The retrospective digest emails to Scrum Master + Project Lead. Scrum Master writes RetrospectiveNotes on the closed Sprint.

Close a sprint without rewriting its history

An unfinished issue can move to the next sprint while the closed sprint still needs an accurate record of what happened. Freeze the closure outcome before moving the current issue. The starting commitment retains its estimate and assignee; the closure observation retains its actual state and accepted estimate at the boundary.

Added and removed work appears separately from the original commitment. Carryover counts original commitment that remains unfinished; completing newly added work cannot cancel out an unfinished commitment or make carryover negative. The sprint keeps its starting estimate unit even if a future project configuration changes. Cancelling a large issue must not look like completing it, and a later estimate change must not improve last month’s velocity. A repeated close command returns the same frozen outcomes and rollover destinations.

The trailing velocity average is a planning aid in the project’s chosen unit. A team with little history does not receive a fabricated capacity promise. Use the suggested value alongside holidays, team changes and known constraints, then retain the sprint goal and accepted scope for the retrospective.