CollectionsField terms59
The vocabulary around daily standups and the agile ceremonies, roles, and artifacts that surround them.
For anyone joining an agile team: engineers, PMs, designers.
Lobyas brings these back across Read, Review and Quiz until they stick.
Invite-only: request access, or use the code you were given.
Read, review and quiz them in Lobyas, with no due dates to fall behind on.
Invite-only: request access, or use the code you were given.
Standup done by posting updates in a channel or tool instead of meeting live.
Example:Everyone drops their three-questions update in #standup by 10am instead of hopping on a call.
The official Scrum term for standup. Same meeting, fancier name in the Scrum Guide.
A separate, smaller conversation spun out of something raised in standup that needed more than a sentence.
Example:'Let's take that in a follow-up after standup' — the standard way of moving a rabbit hole out of the main meeting.
The informal list of topics that come up in standup but get pushed to a separate conversation so the meeting stays short.
Example:Two engineers start debating a database migration approach; Scrum Master says 'parking lot' and they take it to a follow-up call.
Standup format where each person speaks in turn, usually in the same order every day.
Everyone updates their own tickets on the board first, then the group only talks out loud about blockers.
A short daily sync where each person says what they did, what they're doing next, and what's blocking them. Fifteen minutes, tops — if it's running long, it's turned into a status meeting.
Example:9:30am, everyone still standing (hence the name), three questions each, done by 9:45.
The point where standup becomes background noise — people show up but stop actually listening or engaging.
Rotating who facilitates standup each day or week, instead of always having the Scrum Master run it.
Generic term for any short meeting whose purpose is just getting everyone on the same page — standup is one specific kind of sync.
The classic standup format: what did you do yesterday, what are you doing today, what's blocking you.
A hard cap on how long something gets — standup is time-boxed to 15 minutes, meaning it ends at 15 minutes whether or not everyone's finished talking.
Example:Scrum Master cuts off a deep-dive discussion mid-standup: 'let's take this offline, we're time-boxed.'
Running standup by going column by column on the board instead of person by person — you talk about a ticket, not about yourself.
Example:Instead of five people each giving updates, the team moves left to right across the Kanban columns, discussing whatever's stuck.
The full list of work the team could do — everything not yet finished, roughly prioritized.
The recurring session where the team cleans up the backlog — clarifying vague tickets, re-prioritizing, splitting oversized stories, deleting stuff nobody wants anymore.
Same thing as grooming — some teams prefer this term because 'grooming' has an unfortunate secondary meaning.
A big chunk of work too large for one sprint, made up of multiple smaller stories.
Example:'Redesign checkout flow' is an epic; 'add Apple Pay button' is one story inside it.
The complete, prioritized backlog for the whole product, owned by the Product Owner.
A time-boxed task meant to answer a question or reduce uncertainty — not to ship anything, just to figure out how something should be built.
Example:'Spike: investigate whether we can use the existing auth library or need something custom.'
A fixed time window — usually one or two weeks — where the team commits to finishing a set chunk of work.
Example:Two-week sprint: planning on Monday, daily standups throughout, review and retro on the last Friday.
The specific slice of the product backlog the team committed to for the current sprint.
Example:Product backlog has 400 items; sprint backlog is the 12 the team picked for this two-week window.
The one-sentence reason the sprint's work matters — what the team is actually trying to accomplish, not just the list of tickets.
Example:'Ship password reset end-to-end' — not just 'do tickets 401-410.'
A piece of work written from the user's point of view, usually in the format 'As a [user], I want [thing], so that [reason].'
Example:'As a shopper, I want to save items to a wishlist, so that I can buy them later.'
Anything stopping a piece of work from moving forward that the person can't resolve alone.
Example:'I'm blocked, waiting on the API team to deploy their staging fix.'
Same thing as rollover — unfinished work carried into the next sprint.
Splitting sprint work into what the team is confident it'll finish (committed) versus extra work it'll pick up if there's time left over (stretch).
Example:Team commits to 5 stories, adds 2 stretch stories in case they finish early.
Scrum's word for blocker. Same thing, and the Scrum Master's job is specifically to clear these.
Work that doesn't get finished in a sprint and gets pushed into the next one.
A report on what you've done, as opposed to a discussion about what's blocking you.
A smaller piece of work, often a subtask under a bigger story or ticket.
A single trackable unit of work in whatever tool the team uses — Jira, Linear, Asana, whatever.
Example:PROJ-482: 'Fix login redirect loop on Safari.'
A ticket that's technically in progress but hasn't actually moved in days or weeks — nobody's touching it, but nobody's closed it either.
Example:It's been 'In Progress' for three sprints and comes up in standup every day with the same non-update.
The specific, testable conditions a story has to meet to be considered complete.
Example:'User sees an error message if password is under 8 characters' — specific and checkable, unlike 'password validation works.'
The regular rhythm of a team's meetings and cycles — daily standup, weekly planning, biweekly retro.
Scrum's term for any of the recurring scheduled meetings — planning, standup, review, retro.
The team's agreed checklist for when a piece of work actually counts as finished — not just coded, but tested, reviewed, deployed, whatever the team decided.
Example:DoD might include: code reviewed, tests passing, deployed to staging, QA signed off.
The checklist a ticket has to pass before it's allowed into a sprint — clear acceptance criteria, no open questions, properly sized.
Shortcuts taken to ship faster now that cost extra work to clean up later.
Example:Hardcoding a config value to hit a deadline instead of building the proper settings page.
A cap on how many items can sit in a given column (like 'In Progress') at once, forcing the team to finish things before starting new ones.
Example:WIP limit of 3 on 'In Progress' means a 4th ticket can't move there until something else moves out.
A chart showing remaining work in the sprint over time — ideally trending down to zero by the last day.
Like a burndown chart but tracking completed work trending up — and it also shows if scope itself increased mid-sprint.
How much work the team can realistically take on this specific sprint, accounting for holidays, on-call, meetings, and people being out.
Work quietly getting added to a sprint after it's already started, without anyone officially replanning.
Example:Sprint starts with 10 tickets; by day 3 there are 14 because stakeholders kept asking for 'just one more small thing.'
How many story points a team typically finishes per sprint, averaged over recent sprints.
Example:Team's averaging 30 points a sprint over the last three sprints — that's their velocity.
A team with all the skills it needs to ship something end-to-end, without depending on another team for every piece.
Example:One squad with a designer, two engineers, and a QA person, instead of routing every task through three separate specialist teams.
The person who owns the product backlog and decides what gets prioritized and why, based on what's valuable to users and the business.
The person responsible for running the ceremonies, clearing impediments, and protecting the team from process nonsense — not a manager, not a project lead.
A small, semi-autonomous cross-functional team, popularized by Spotify's org model — same idea as a scrum team, different label.
Anyone outside the immediate team with an interest in what's being built — a client, an exec, another team depending on the output.
Example:Marketing is a stakeholder for a feature launch even though they're not writing any code.
A concrete, assigned change agreed on in retro — not just a complaint, an actual thing someone owns doing.
The meeting at the start of a sprint where the team picks which backlog items to commit to and roughly how they'll get done.
End-of-sprint meeting about how the team worked, not what it built — what went well, what didn't, what to change next sprint.
Example:'Standups kept running over because we were debugging live — let's take debugging offline next time.'
End-of-sprint meeting where the team demos what got built to stakeholders and gets feedback.
An estimation exercise where everyone privately picks a point value and reveals at the same time, to avoid anchoring on the first number said out loud.
A relative unit for estimating effort — not hours, just a rough comparison of how big one story is versus another.
Example:A login fix might be 2 points; a full new checkout flow might be 13.
An estimation method where stories get sized as XS/S/M/L/XL instead of numeric points — rougher, faster, no false precision.
Example:'That's obviously an M, let's not spend ten minutes debating 5 vs 8 points on it.'
A flow-based alternative to Scrum — no fixed sprints, work moves continuously through columns on a board, limited by WIP limits instead of time-boxed iterations.
The most common agile framework — fixed-length sprints, defined roles (Scrum Master, Product Owner, dev team), and a set ceremony cadence: planning, daily scrum, review, retro.
A mashup of Scrum and Kanban — sprints and ceremonies from Scrum, continuous flow and WIP limits from Kanban.