How Teams Actually Finish What They Start, Part V: The Sprint as a Working Set

Tue, 05 May 2026 00:00:00 +0000

TL;DR

For teams whose week is shaped by inbound work, the sprint should hold only what is being worked on now plus what gets pulled next. No forward estimates, no velocity commitments. Priority lives in labels; the team pulls from the labeled backlog as in-flight work completes.

Tuesday at 2pm. Sprint planning. The team has been here for ninety minutes. Eighteen tickets on the board, points being argued about (was this a 5 or an 8 last quarter?). A senior engineer flags they have to leave for an interview at 3. The product manager wants to commit to 42 points so the velocity curve in the leadership deck stays smooth. Three operational tickets came in during the meeting itself. Nobody has touched code today. The sprint will start tomorrow with eighteen tickets the team has not properly looked at, plus the three that arrived during planning, plus whatever arrives over the next two weeks. The planning meeting was the work today.

Better grooming doesn’t fix it

The standard fixes target the planning meeting: better grooming, T-shirt sizing instead of points, async estimation in Slack. Each saves twenty minutes and leaves the underlying mistake intact. The mistake is the sprint trying to be a committed plan for two weeks of work the team has not done yet, on a team whose two weeks are not predictable. No amount of grooming makes the unpredictable predictable. The fix is a sprint that admits it.

The sprint as a working set

A different mode: the sprint holds only what is being worked on right now, plus the highest-priority items the team will pull next. That is it. The sprint stops being a two-week forecast or a velocity commitment. The board reflects reality rather than narrating it.

The mechanics follow. The backlog holds everything, labeled by priority. The manager keeps the labels current, and high-priority items rise to the top of the filtered view. The sprint holds only tickets currently in progress plus immediate next pulls. Engineers pull from the labeled backlog into the sprint as their current work completes. There is no forward estimation at planning, because points are written post-hoc (see Part IV). Planning becomes a short check-in: the team confirms priorities, surfaces blockers, and returns to work.

Engineers file their own tickets when they discover work. A bug found while shipping a feature. A refactor that surfaces during code review. A dependency that needs chasing. The IC who found it writes the ticket. “Someone will write this up later” becomes nobody, and the work disappears from the tracker without disappearing from reality. The team’s tracker has to hold the team’s actual work; if the work is not in the tracker, the work does not exist for planning purposes.

The responder rotation absorbs incoming interruption tickets (Part III) so the sprint is not churned by every Slack message and every cross-team request. The sprint is what the team is building. The responder column is what arrives. The two queues stay separate, and the sprint stays small.

The sprint is not a copy of the backlog

The pressure to grow the sprint is constant. Leadership wants velocity numbers, the team wants to look ambitious, every new priority feels like it should land “in this sprint.” It should not. The sprint is what the team is doing now plus what they will pull next. If the sprint contains tickets nobody has looked at, the discipline has slipped, and the velocity that comes out the other side is fiction.

In the tracker

Jira gives you priority fields, labels, components, ranks, epics, and themes. The working-set sprint needs three things from the tracker: a backlog the manager can prioritize, a way to see the labeled top of the backlog, and a sprint board that shows what the team is doing right now. The rest is decoration.

A workable setup: priority lives on a single field or a single label, picked once and used consistently. A saved filter (JQL or board view) shows the labeled high-priority backlog, and that filter is the team’s entry point when their current ticket closes. The sprint board shows in-progress and next-up tickets only. Standups walk that board ticket by ticket. Estimation columns are optional; if used, they are filled in after the ticket closes, not before.

Use one priority mechanism, not three

Jira lets you mix priority field, labels, components, and rank order. Pick one. A label like priority:p0 works. So does the built-in priority field. Mixing them means engineers pull from one filter while the manager updates another, and the team works on the wrong tickets while the tracker says everything is fine.

When forward sprints work

A team with a stable, well-scoped backlog and predictable interruptions can run forward sprints with point commitments. Some maintenance teams have this. Some platform teams whose remit has been narrowed and frozen do too. For everyone else, the working-set sprint is the one that matches reality. Part IV’s measurement discipline is how the team finds out which side it is on; the working-set sprint is what the team does with the answer.

What changes

Sprint planning gets short. Velocity stops being a fiction the leadership deck has been running on. With the board reflecting actual work, the rest of the cadence gets honest too. Standups walk the board ticket by ticket and finish in fifteen minutes. Retros talk about what actually happened, not about the gap between estimate and reality. And reviews compare engineers on the same shapes of work, with the data Part IV produced. The tracker stops being a stage for the planning ritual and becomes a tool for getting work done.