task-ops
Most sprints do not fail at the end. They fail in the forty minutes when the team decides what goes in. The list looks reasonable on the screen, everyone nods, and by Wednesday two people are working on something that was never discussed. The sprint backlog was written down, but it was never really a plan.
The word "backlog" is part of the problem. It suggests a queue of things waiting their turn. The sprint backlog is not that. It is the current best answer to a question the team has to keep answering: given what is known today, what is the shortest path to the outcome this sprint promised?
The Scrum Guide is unusually specific here, and the specificity matters because most teams only keep one of the three parts.
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how). Source: scrumguides.org
Nearly every team keeps the middle part. The selected items exist as cards on a board, with owners and estimates. The goal is often written once in a field nobody opens again. The plan, the actual "how", usually lives in people's heads or in a chat thread from the first day of the sprint.
That imbalance is what produces the familiar mid sprint drift. When only the item list is visible, any decision about sequencing, dependencies or who picks up what next has to be renegotiated verbally. When the goal is not visible, there is no shared test for whether a new request belongs in this sprint or the next one.
A practical version of all three parts on one board looks like this. The goal sits at the top of the board as a single sentence, not a paragraph. The selected items sit in columns that describe state, not department. The plan shows up as the decomposition inside each item plus the order of the column, because order is a decision even when nobody calls it one.
The plan is the part that has to change, and the part most boards make hardest to change. A reordered column, a task split in two, a dependency noted on a card: those are plan edits. If editing the plan requires a conversation with whoever owns the board, the plan stops being maintained by day three.
The Scrum Guide puts ownership somewhere that surprises managers who are new to it.
The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Source: scrumguides.org
The product backlog is ordered by the product owner. The sprint backlog is not. Once the sprint goal is agreed, how the work gets done sits with the people doing it. The guide is explicit that decomposition into items of a day or less "is at the sole discretion of the Developers."
This distinction is worth defending, because the failure mode is quiet. A manager who reassigns cards, reorders the column, or adds tasks on behalf of the team is not obviously doing harm. Each individual edit looks like help. The cumulative effect is that the team stops treating the board as theirs, and the board becomes a report written for someone else. Reports get updated before meetings. Plans get updated when something is learned.
There is a second reason ownership matters for anyone coordinating several teams. If the sprint backlog is owned by the team, it can be trusted as a signal. If it is edited from outside, every number derived from it, including the burndown, is measuring the editing rather than the work.
The coordinator's job is not to arrange the cards. It is to make sure the goal is unambiguous, that dependencies on other teams are visible before the sprint starts, and that nobody outside the team is adding scope without a conversation.
Confusing the two is the most common structural mistake, and it usually shows up as a single enormous board where everything lives.
| Product backlog | Sprint backlog | |
|---|---|---|
| Time horizon | Open ended | One sprint |
| Ordered by | Product owner | The team doing the work |
| Contains | Items, roughly sized | Goal, selected items, plan |
| Changes when | Anytime, continuously | During the sprint, as more is learned |
| Item size | Weeks down to days | A day or less where practical |
| Deleted or kept | Kept and reordered | Emptied at sprint end |
The horizon difference is the one with practical consequences. A product backlog is allowed to contain vague items, because refining something a team will not start for three months is waste. A sprint backlog is not allowed to contain vague items, because a vague item cannot be finished and cannot be honestly reported as in progress.
Refinement is the bridge between the two. It is not a ceremony that needs its own meeting series. It is the ongoing work of taking the next several items at the top of the product backlog and making them concrete enough that sprint planning is a selection decision rather than a research session. Teams that skip refinement spend sprint planning discovering what the work is, which is why planning runs long and the resulting plan is thin.
Capacity is where optimism does the most damage, and the fix is arithmetic rather than discipline.
Start with the number of working days the team actually has. Subtract known absence, public holidays, and the recurring meetings that are not the sprint's work. For a five person team over a two week sprint, the theoretical fifty person days often lands nearer thirty five once support rotations and interviews are counted. The gap between fifty and thirty five is not a productivity problem. It is a measurement problem, and it explains most sprints that end at eighty percent.
Then apply the team's own history rather than a target. Whatever unit is used, story points, item counts or days, the useful figure is the median of the last three to five sprints, not the best one. The best sprint is the one everyone remembers and the one least likely to repeat.
Two adjustments are worth making explicitly. First, reserve capacity for the work that arrives without warning. Teams carrying production support usually find that the unplanned share is stable enough to budget for, and budgeting for it is far less disruptive than absorbing it silently. Second, leave the last item of the sprint slightly loose. A sprint packed to the last hour has no room to accommodate what gets learned, and learning is the thing the sprint was supposed to produce.
If the team consistently finishes early, the problem is worth having and easy to fix. If it consistently finishes at ninety percent, the plan is being written for the wrong capacity number.
The guide expects change: "the Sprint Backlog is updated throughout the Sprint as more is learned." That sentence is often quoted to justify anything at all, so the line is worth drawing precisely.
Adding tasks is not adding scope. Discovering that a selected item needs a database migration nobody anticipated means the plan was incomplete, and completing the plan is exactly what the sprint backlog is for. No conversation with the product owner is required. The goal has not moved.
Adding a new item is adding scope. A request that arrives on day four, however small, changes what the sprint is committing to. That is a negotiation, and the honest version of it names what comes out. Sprints that absorb new items without removing anything are how a burndown line goes flat for a week and then falls off a cliff on the last day.
Removing an item is also legitimate. If the team learns that a selected item cannot reach the definition of done this sprint, saying so on day five is worth more than discovering it on day ten. The sprint goal survives losing an item far more often than teams assume.
The test to apply, in every case, is whether the sprint goal still holds. If the goal holds, the change is a plan edit and the team decides. If the goal does not hold, the change is a scope decision and it needs the product owner in the room.
Almost every stale board has one of three causes, and none of them is laziness.
The first is friction. If updating a card takes more than a few seconds, or requires opening a second tool, the update happens at the daily meeting instead of when the work happens. A board that is accurate once a day is not a real time picture, and decisions made against it are made against yesterday.
The second is a split between where work is discussed and where it is recorded. When the decision to change approach happens in a chat thread and the card is never touched, the board and the truth diverge by exactly the volume of the conversation. Keeping discussion attached to the item it concerns is the single highest leverage change most teams can make, and it is the reason boards with built in per item chat tend to stay closer to reality than boards that link out to a separate messaging tool.
The third is too many boards. Teams that split work across a board per project, a board per client and a board per quarter end up with no single place that answers "what is this sprint." Tool pricing quietly shapes this: plans that meter boards push teams toward fewer, larger boards, while plans that meter people push them the other way. Trello's free plan, for instance, allows "Up to 10 boards per Workspace" and is "Free for up to 10 collaborators per Workspace," with Standard at $5 per user per month billed annually according to its pricing page. Comparing how different tools draw those lines is worth doing before a team commits, and a side by side comparison makes the trade explicit.
There is a fourth cause that is really a symptom: the board exists to be reported on. If the only time anyone looks at it is a status meeting, it has already stopped being a plan. The fix is not a better board. It is giving the team a reason to look at it for their own benefit, which usually means the board is also where the sequencing decisions are made.
Pick the smallest of the three parts that is missing. If the sprint goal is not written as one sentence somewhere everyone can see it, write it before the next sprint starts, because every other decision depends on it. If the goal exists but the plan does not, spend fifteen minutes at the end of planning decomposing the top two items and put the order of the column in writing.
If the board itself is the friction, the test is whether a card can be updated, discussed and reordered without leaving the screen. Tools that keep kanban, Gantt and per item conversation in one place remove the excuse for updating late, and Pinateca is free for up to 5 people and 10 boards, which is enough to run a real sprint before deciding anything.
The team doing the work adds tasks freely, because completing the plan is their responsibility. Adding a new product backlog item is a different decision and needs the product owner, since it changes what the sprint is committing to. The practical test is whether the sprint goal still holds after the change.
Yes. Items that were not finished go back to the product backlog and get reconsidered in the next planning session rather than rolling over automatically. Rolling items over hides the fact that they were selected optimistically, and it makes velocity figures meaningless after two or three sprints.
Detailed enough that progress can be inspected daily, which usually means work items of about a day or less. Going finer than half a day tends to create bookkeeping without improving visibility. The level of detail is the team's decision, not a standard to be imposed.
In Jira they do not. The documentation states that "Story Points on subtasks are not included in the Burndown Chart" and that only points on parent tasks count, so a team that estimates at subtask level will see a flat chart. Check where the tool in use reads its estimate from before trusting any chart built on it.
Yes, but the overhead should be small. One visible goal, the selected items on a single board, and an agreed order is enough. What a small team gains is not process. It is the ability to say no to a mid sprint request by pointing at something concrete rather than arguing about how busy everyone is.