How a Scrum sprint runs
Two weeks in the life of a Scrum team — backlog, refinement, planning, the daily standup, the work itself, the review, the retrospective and the increment that ships.
A product backlog of ideas
A sprint is a fixed box of time, usually two weeks, and this is what feeds it. The product backlog is one ordered list of everything anyone wants, kept in strict priority order rather than sorted into neat themes, because a list can only have one top.
The product owner ranks it
One person, the product owner, decides that order, and that single point of accountability is the quiet genius of the whole framework. Ten stakeholders can argue all they like, but only one list exists and only one person is allowed to renumber it.
Refinement sizes the top items
Refinement is the team reading the top of the list ahead of time and sizing it, usually in story points rather than hours. Points compare items against each other, which humans are far better at than guessing durations, and after three or four sprints the numbers get genuinely useful.
Planning agrees a sprint goal
Planning day opens with a question: what is worth achieving in the next two weeks? The answer is one sentence, the sprint goal, and it matters more than the ticket list, because it is what lets the team drop scope later without failing.
The team pulls what it can finish
Then the team pulls work in, and that word pull carries a lot of weight. Nobody hands a sprint to a team. What the team gives is a forecast of what it can finish, based on the uncomfortable evidence of last sprint, and a real commitment to one thing only: the goal.
The clock starts, scope locks
The clock starts and the scope locks. For the next two weeks nothing new gets pushed in, and that protection is the single most valuable thing a sprint offers: a fortnight in which the plan does not change under your feet halfway through Wednesday.
A fifteen minute daily standup
Every morning, fifteen minutes, standing up so it stays fifteen minutes. It is not a status report to a manager. It is the team resynchronising with itself and deciding what happens today, and the moment it turns into a progress interrogation it has stopped working.
Is anything blocked?
The real payload of a standup is the question about obstacles: what is in my way? A blocker named out loud on Tuesday morning costs an hour of somebody's time. The exact same blocker discovered at the review, twelve days later, costs the whole sprint.
The scrum master clears the path
Clearing that is the scrum master's actual job, and it is not project management. Chase the missing test environment. Get the answer out of the other department. Say no, out loud, to the person trying to slip extra work in on day six.
Work meets the definition of done
Work only counts as done when it meets the definition of done, a checklist the team wrote once and applies every single time: tested, reviewed, documented, deployable. Without one, done quietly means whatever the most optimistic person in the room thinks it means.
The burndown shows the real pace
The burndown chart plots work remaining against days left, and its real value is that it lies badly. A flat line for six days followed by a cliff is the classic signature of a team starting everything and finishing nothing, and it is visible long before anyone admits it.
Sprint review with stakeholders
Then comes the review, capped at about two hours for a two week sprint, where the rule is that working software is shown, never slides. Stakeholders touch it and quite often discover that what they asked for is not what they wanted, which is precisely why you ask again every two weeks.
The retrospective looks inward
The retrospective turns the lens on the team itself. What helped, what hurt, what will we change? It is the only meeting whose subject is the process rather than the product, and it is the first one a team under pressure wrongly decides to skip.
One improvement is chosen
Its output is not a list of complaints, it is one concrete experiment for next sprint: one change, owned by a named person, checked at the next retrospective. Teams that leave with five improvements reliably deliver none of them.
A usable increment ships
And what ships is an increment: a working, usable slice of the product, not a phase of a project. That is the whole bet of Scrum, that a small real thing in real hands every two weeks teaches you more than a beautiful plan ever will.
Watch it explain itself
Every step above is narrated aloud. Play it, or open it in the editor and make it yours — no account needed.