What is a sprint, and what does Agile mean?

What is a sprint, and what does Agile mean?

A sprint is a fixed cycle of work, usually one or two weeks, and Agile is the working style built around cycles like it: plan a little, build, ship, learn, and adjust. Together they answer a question the earlier lessons raised without settling. Software is never finished, and shipping is a pipeline that runs constantly, so someone has to decide what the team builds this week and what waits. Agile is the machinery for that decision.

This lesson covers the four words that machinery runs on: sprint, ticket, backlog, and standup. They are the first vocabulary an engineering manager will use in a kickoff or an intake, and every one of them has a plain meaning. By the end, a sentence like "it's in the backlog, we'll pick it up next sprint, I'll flag the blocker at standup" reads as the schedule update it is.

What is Agile?

Agile is a way of organizing software work around short cycles and steady feedback instead of one long upfront plan. The older model, often called waterfall, ran like construction: gather every requirement, design the whole thing, build for months, then deliver. It failed often for software, because software requirements change while the work is happening. Users react to what ships, competitors move, and the team learns things mid-build that the plan never anticipated. Agile accepts that and plans in small increments, so the plan can bend without the product stalling.

The word comes from a 2001 document called the Agile Manifesto, written by a group of developers, and the values in it are short: working software over heavy documentation, responding to change over following a plan. Everything else grew up around those values as named methods. Scrum is the most structured one, with fixed roles and fixed meetings. Kanban is a looser version where work flows continuously through columns like "to do", "in progress", and "done". Most real teams run a blend and rarely name it. When a hiring manager says "we're agile" or "we run two-week sprints", they are describing this family of habits.

The mechanics from the previous lesson are what make it possible. A team can only promise working software every two weeks because CI/CD lets it deploy that often and roll back safely when something breaks. Agile is the planning layer sitting on top of that delivery layer.

What is a sprint?

A sprint is one cycle of the loop: a fixed window, usually one or two weeks, that a team plans at the start and reviews at the end. In sprint planning, the team picks the work it believes it can finish in the window. During the sprint, that scope is meant to stay stable so people can concentrate. At the end, the team demos what got done, looks at what did not, and feeds both into planning the next one. Many teams add a retrospective, a short meeting about how the process itself went.

The name misleads a little. A sprint in athletics is a burst you recover from, but software sprints run back to back all year with no rest between them. The word was chosen for focus rather than speed. A better mental model is a heartbeat: a steady, repeating rhythm the whole team synchronizes on.

Sprints are why engineering commitments come in a distinctive shape. "We can start that next sprint" means the current window is full and the new work enters the next planning round. That answer reflects a system that protects focus, and it is the normal texture of a healthy team rather than reluctance.

What is a ticket, and what is the backlog?

A ticket is one unit of tracked work: a short description of what needs doing, an owner, and a status. A new feature is a ticket. A bug report is a ticket. A chore like upgrading a library is a ticket. Tools like Jira, Linear, and GitHub Issues exist to hold them, and "filing a ticket" means writing the work down in one of those tools so it can be scheduled. Bigger units exist too: many teams group tickets into "epics", and some size tickets in "story points", an abstract effort estimate used for planning.

The backlog is the ordered list of tickets the team has agreed matter but has not started. Order is the important part. The top of the backlog is next; the bottom may sit for a year. Sprint planning is largely the act of pulling the top items off the backlog into the sprint. "It's in the backlog" therefore means the work is acknowledged and queued, and how high it sits tells you how soon it will be real. This is also where technical debt competes for attention: cleanup work only happens when a ticket for it gets prioritized above something shiny.

For a sense of what fills the queue, tickets track exactly the work the previous lessons described. Each one typically becomes a branch, then a pull request, then a deploy, so the planning vocabulary and the shipping vocabulary describe the same work at two altitudes.

What happens at a standup?

A standup is a short daily meeting, usually ten to fifteen minutes, where each person says three things: what they did yesterday, what they are doing today, and whether anything is blocking them. The name comes from the custom of standing to keep it brief. Remote teams often run it in chat instead, with everyone posting the same three lines.

The blocker is the part that matters. A blocker is anything stopping work from moving: waiting on a code review, waiting on a decision, waiting on access to a system. Standup exists so blockers surface within a day instead of festering silently for a week, and the manager's real job in the meeting is clearing them. Sit in on one and the rest is recognizable: it is a pipeline review, run daily, with tickets as the deals.

What is a roadmap?

A roadmap is the long-range plan sitting above all of this: the sequence of major things the team intends to build over the next few months or quarters. Where the backlog is precise and constantly reordered, the roadmap is coarse and directional. "Payments revamp in Q3, mobile app in Q4" is roadmap language.

The two layers connect top down. A roadmap item gets broken into epics, epics into tickets, tickets into sprints. So when a candidate says they "led the search revamp on the roadmap", they are claiming work at the top of that chain: shaping a large goal and decomposing it, which is a bigger scope than completing tickets someone else wrote. On healthy teams the roadmap changes when the evidence does, and that is the Agile part working as designed. A release teaches the team something, and the plan absorbs the lesson.

Why do developers roll their eyes at the word Agile?

The eye-roll comes from the gap between the idea and its heaviest implementations. The manifesto asked for less process. What many companies built in its name was more: daily meetings that run long, estimation ceremonies that take hours, certified process roles, and metrics like story-point counts that get mistaken for productivity. Developers call this "agile theater" or capital-A Agile, process worn as costume. Someone who has lived through it hears the word and remembers the meetings.

The idea itself is close to universally accepted. Almost every developer prefers short cycles, fast feedback, and plans that bend, which is small-a agile, and most would rebuild it on any team that lacked it. So a wince at the word usually carries information about past process pain and none about attitude toward teamwork. A developer venting about standups that run forty-five minutes is often the person who most wants the ten-minute version.

The same reading applies in the other direction. Fluency with this vocabulary tells you someone has worked on collaborative product teams, given and received estimates, and been planned with. It says nothing on its own about how well they code, which lives in their actual work. The two signals are independent, and this module has now given you both halves: how software gets built, and the rhythm the builders move to.