Sprint Backlog

A sprint is a work cycle of fixed length, usually somewhere between one and four weeks. Fixing the length by itself changes very little. A team can spend the first morning choosing what to do and still end up, two days later, with three different versions of that decision living in three different heads.

The middle of such a cycle tends to go the same way everywhere. The founder catches a developer in the hallway and asks for one urgent thing. Sales brings in a customer request separately. The designer assumes the screen they handed over last week made it into this cycle and waits for it. On the last day, at the review, everyone discovers they had been expecting different work. Nobody lied at any point, and yet the result looks exactly like a broken promise.

A sprint backlog exists to end that state with a single list. Everything the team agreed to do this cycle is written in one place, and anything not on the list is work the team is not doing this cycle. Because the list is open to people outside the team, someone arriving with an urgent request can see what they are asking the team to trade away, and the conversation starts from that trade instead of from the urgency.

One line of purpose, the work chosen to serve that purpose, and a size and a status on each item. Once those four are present, the list alone tells you how far the cycle has gotten.

1. Sprint goal — a single sentence saying what the cycle is meant to achieve, such as "a free user can get all the way to payment without getting stuck." When an item has to drop out, this sentence is what tells you whether the rest of the plan still holds or has to be rebuilt.
2. Work items — the list of things chosen for this cycle, usually taken from the top of an ordered list of candidates. They are most often written as user stories, meaning a single sentence stating what a user wants, like "I want to download my payment history."
3. Tasks — each item broken into steps concrete enough to pick up and start. "Download payment history" splits into building the endpoint, wiring the screen, and writing the tests. Teams aim for pieces that take between half a day and two days, because anything longer hides its own progress.
4. Size and status — each item carries a story point value. A story point describes relative size rather than hours, assigned from a scale like 1, 2, 3, 5, 8. Status is most commonly three columns: to do, in progress, done.
5. Definition of done (DoD) — the checklist the team uses to decide what counts as finished, typically reviewed, tested, and running in production.

What stays out is just as definite. Candidates for the next cycle, ideas worth doing someday, and the request a customer made yesterday all belong to the list one stage upstream, not to this one. A team that loads thirty items and finishes twelve of them every cycle is running two lists stacked on top of each other and calling the pile a plan.

The people doing the work write it. During sprint planning the development team picks the items themselves and breaks them into tasks. Deciding what comes first is the job of whoever owns the product, but deciding how far down that order the team can reach is the team's own call. A team that has finished an average of 32 points across the last three cycles pushes back on a 40-point plan in the room, before the cycle starts. That average is called velocity.

Changing the list mid-cycle is also the team's job. At the daily scrum they move yesterday's finished work into the done column, and when the work turns out to need one more task they add it on the spot. The list keeps moving on the inside while staying closed on the outside.

Readers come in two layers. The first is the team itself, which uses the list to decide what to pick up today and to see where someone is stuck. The second is everyone outside the team who wants to know how the cycle is going: sales checking whether a feature promised to a customer made it in, the founder seeing what the team is spending these two weeks on. That second layer gets read access only. Anyone who wants the order changed either waits for the next planning session or proposes which item currently in the list should come out to make room.

When the cycle ends, the list is emptied and filled again. Only the items that met the definition of done survive as the increment, the working result added at the end of the cycle.

"That's not in this sprint backlog. Let's raise it at the next planning."

Not squeezing it in now, and arguing about its position when the next cycle is planned.

"I added two tasks but didn't touch the points."

The scope of the agreed work is unchanged; only the execution steps were split finer.

"There are 40 points left and three days in the cycle."

The team took on more than the remaining time holds, so something has to come out.

At Pagedeck this list is open to the whole company. Sofia goes looking for the download feature she promised a customer, sees it isn't in this cycle, and asks Mia. Mia opens the five items currently in the list and they pick together what would have to come out to make room. When Grace arrives with something urgent, they look at the same screen. Without the list, "can you get this in quickly" is where the conversation ends. With it, the conversation runs all the way to "then this one moves to next cycle."

The most common reading is that once the list is set, nobody may touch it until the cycle ends. It's easy to arrive there from the rule about outside requests being kept out. What actually locks is the door from outside; the team adds tasks and changes its approach all the way through. Freeze the list and a team that learns on day three that its first-day guess was wrong will keep spending two more days on the wrong work anyway.

Reading it as a progress report for managers is the other frequent mistake, and people outside the team really do look at it, so the impression is understandable. But its first reader is the team deciding what to pick up today. Once it starts serving as a report, the team grooms it to look good: finished work gets recorded carefully and blocked work gets moved late. A tool built to surface blockers early becomes the place they hide.