Agile, Scrum, Sprints, Standups: a junior dev's guide

By the end of week one at your first software internship, you will have heard "sprint," "standup," "story points," "groomed backlog," "retro," "JIRA," and "ticket" so many times that nobody remembers to explain them. Most of it is simpler than it sounds. This guide is the plain-English version of every Agile term you'll meet, plus what your job actually is in each ceremony.

The 30-second version

Agile is a philosophy: ship small bits of working software often, instead of one giant release. Scrum is the most popular way teams actually do Agile in practice, and it gives names to a few specific meetings and roles. A sprint is a fixed window (usually 1 to 2 weeks) where the team commits to a small batch of work and ships it. The standup is the 15-minute morning meeting during a sprint. That's roughly 80% of what you need to know.

Agile vs Scrum vs Kanban

People use these words interchangeably and they shouldn't. Quick map:

• Agile is the philosophy. The original Agile Manifesto from 2001 boils down to four ideas: working software over comprehensive documentation, individuals over processes, customer collaboration over contracts, and responding to change over following a plan.
• Scrum is a specific framework that implements Agile. Fixed-length sprints, named ceremonies, named roles. About 60 to 70% of tech teams use some flavor of Scrum.
• Kanban is a different framework. No fixed sprints, just a continuous flow of tickets through columns (Todo, In Progress, In Review, Done). Common at small teams and at companies with operational/support work.
• "Scrumban" is a hybrid that some teams use. Sprints exist, but they're loose, and tickets flow through Kanban-style columns.

You can't do Scrum without doing Agile, but you can do Agile without Scrum. You'll usually find out which framework your team uses on day one, often by looking at how their Jira board is configured.

The Scrum ceremonies, what they actually are

Scrum has four recurring meetings. Names vary by company but the ideas are universal.

Sprint planning (1 to 2 hours, start of each sprint)

The team looks at the backlog of upcoming work, picks what to commit to for the sprint, and assigns initial owners. As an intern, your job here is mostly to listen and pick up tickets that match your skill level.

What to do well: when a ticket is being discussed and your manager looks at you, ask one clarifying question. "Does this require any frontend changes too, or is it backend-only?" That signals you're paying attention without over-promising.

Daily standup (15 min, every weekday)

Each person says three things: what I did yesterday, what I'm doing today, what's blocking me. Sometimes called "the daily" or "standup." The whole point is communication, not status reporting to your boss. If you finish in under 15 minutes, the team is doing it right.

Your standup script as an intern, day one through forever:

Yesterday: "I set up the dev environment and got the test suite running."
Today: "Reading the auth module to start on TICKET-1234."
Blockers: "None right now, but I might have a question about how
           the JWT secret is loaded by end of day."

Three sentences. Mention blockers proactively, not at the end of the day when it's too late.

Sprint review / demo (30 to 60 min, end of sprint)

The team shows what got built. Sometimes called "sprint review," "demo," or "show and tell." Stakeholders (product, design, sometimes leadership) attend. Each engineer briefly walks through what they shipped.

Your first time presenting will be week 6 to 10 if you've shipped something. Keep it short: what was the problem, what did you build, here's it working. 90 seconds is plenty for an intern's first feature.

Retrospective / "retro" (45 to 60 min, end of sprint)

Internal-only meeting where the team talks about how the sprint process went, not what got built. Common formats: "what went well, what didn't, what should we change?" or "start, stop, continue."

As an intern, you can absolutely contribute. Good first retro contributions:

• "Onboarding doc was helpful, but it was missing the bit about regenerating the local DB. I'd add a section."
• "Standups felt long this sprint, maybe because we had two new tickets being scoped during them?"
• "Pair-programming with Mike on Tuesday unblocked me in 30 minutes for something that was going to take all day. More of that."

Specific, observed, and tied to something concrete. Not "everything's fine" (low signal) and not "I think the whole process is broken" (overstepping).

The Scrum roles

Three roles you'll hear named:

• Scrum Master. The person whose job is to run the ceremonies and unblock the team. Not your boss. Often rotates among engineers, or is a dedicated role at bigger companies. Their job is process, not deciding what to build.
• Product Owner / Product Manager (PM). The person who decides what the team should build next, based on customer / business / strategic input. They write or curate the tickets. Your PM is who you talk to when the requirements on a ticket are unclear.
• Dev team. The engineers, including you. Decides how things get built and how long they'll take.

"How long will it take" is your area, not the PM's. Don't let a PM tell you a thing will take two days when you know it'll take five. Push back politely.

Tickets, stories, epics, story points

Tickets / stories

A ticket is a single unit of work, usually about a day to a few days of effort. "Story" is the formal Scrum word for the same thing, often written as: "As a user, I want X so that Y." Most teams just say "ticket."

Every ticket should have: a clear description, acceptance criteria (what counts as done), and a reasonable size. If yours doesn't, ask before starting.

Epics

An epic is a big container of related tickets. Example: an epic might be "Add OAuth login," and it would contain 8 to 12 individual tickets ("Set up OAuth client config," "Add login button to navbar," "Write tests for the redirect flow," etc.). You'll work on tickets, not epics.

Story points

Most controversial concept in Scrum. Story points are a relative size estimate, not a time estimate. A 1-point ticket is "this is trivial, an hour or two." A 5-point ticket is "this is meaty, maybe two or three days." A 13-point ticket should probably be split.

Why use points instead of hours? In theory, points abstract away who's doing the work (a senior is faster than a junior on the same ticket). In practice, points often become hour-equivalents in disguise. Some teams use Fibonacci numbers (1, 2, 3, 5, 8, 13). Some teams use t-shirt sizes (S, M, L, XL). Some teams skip points entirely.

As an intern, your only job with points is: when asked "how big do you think this is?", give an honest gut estimate and be open to your team adjusting it.

Velocity

How many points the team typically completes per sprint. Used for predicting how much can fit in the next one. If your team has a velocity of 25 and there are 40 points in the next sprint plan, something has to come out.

Backlog, grooming, refinement

Backlog = the prioritized list of upcoming tickets, typically owned by the PM. Top of the list = ready to work on. Bottom = vague ideas.

Backlog grooming / refinement = a meeting (usually weekly) where the team takes upcoming tickets and clarifies them: adds acceptance criteria, gets a rough size estimate, asks blocking questions. Goal: anything that goes into a sprint is "ready," meaning small, scoped, and unambiguous.

You'll hear "this needs grooming" often, which means: this ticket is too vague or too big to start work on yet.

Definition of Done (DoD)

Most teams have a written or unwritten checklist for "this ticket is actually done." Common items:

• Code is written and pushed.
• Tests are written for new behavior.
• CI is passing.
• PR has been reviewed and approved.
• Code is merged to main.
• The change is deployed (to staging or production).
• If user-facing: PM has signed off.
• Documentation updated if needed.

Ticket isn't "done" until all of these are true. "I wrote the code" is not done. "I pushed but didn't merge" is not done. Get clear on your team's DoD in your first sprint.

The Jira basics

Jira is the dominant ticket tracker (Atlassian product). Linear, Asana, ClickUp, GitHub Projects, and Notion-as-tracker are common alternatives. The mechanics are similar across all of them.

What you'll do daily:

• Move tickets across columns. Todo → In Progress when you start. In Progress → In Review when your PR is open. In Review → Done when it merges.
• Comment. Anything that happened (decision, blocker, design change) goes in a ticket comment so the team has context.
• Link your PR. Most teams expect the PR description to reference the ticket (e.g. "Closes JIRA-1234"), and the ticket to link to the PR.
• Update the description if the scope changes. If you discover the bug is bigger than expected, update the ticket so future readers know.

What "Agile" looks like when it's bad

Agile is often poorly implemented. Signs of a process that's gone wrong:

• Standups that run 45 minutes. Means people are problem-solving in the meeting instead of after it.
• Tickets with no acceptance criteria. Means "done" is whatever the engineer feels like.
• Sprints that always slip. Means the team is over-committing or estimating badly.
• Retros that never produce changes. Means the team is going through the motions.
• Story points used to grade engineers. Means management has misunderstood the point of points. Ignore it as best you can.
• "We're Agile" used to justify never having a plan. Real Agile has plans, just shorter ones.

You'll experience at least one of these in any internship. Don't try to fix the process as an intern, that's not your job and it'll backfire. Just internalize what good looks like for later.

What you can ignore as an intern

You don't need to deeply understand: SAFe (Scaled Agile Framework), the entire Scrum Guide, the difference between commitment and forecast in modern Scrum, the certifications (CSM, PSM, SAFe Agilist). Those are job titles for someone else.

The minimum viable Scrum knowledge for an intern is the contents of this guide. You can build the rest as needed.

The single thing that matters most

Communicate proactively. Agile / Scrum is mostly a system of meetings and rituals to enforce frequent communication. If you do that part well even outside the rituals, the rest is just vocabulary.

That means: post in standup if you're stuck. Update the ticket when you discover a wrinkle. Comment on the PR when you're confused. Slack your manager if you're going to miss a deadline. The teams that work well are the ones where information flows quickly. Be a node that flows.