glossary · general
Scrum in product management
A time-boxed iterative framework where cross-functional teams build toward a Sprint Goal every one to four weeks, then inspect the increment and adapt before the next cycle.
Scrum is a decision-making system, not a set of rituals. Formalized by Ken Schwaber and Jeff Sutherland in 1995 and maintained at scrumguides.org, it structures work into fixed cycles called sprints so teams surface whether what they are building is actually wanted before committing months of effort to the wrong thing. Naming the ceremonies is table stakes in an interview. What clears the bar is showing you understand your specific job in each one, where the model breaks, and when to reach for something else.
PM vs. Product Owner: the role confusion interviewers test
The Scrum Guide defines three roles: Product Owner (decides what to build and in what order), Scrum Master (coaches the team on process), and Developers (build the increment). At smaller companies the PM and PO are the same person. At larger orgs they split: the PM owns strategy and roadmap; the PO owns the backlog and is the day-to-day decision authority for the team. If you are interviewing at a company where the roles are separate, your accountability shifts toward discovery and away from backlog operations. Know which world you are walking into.
The Scrum Master is not a project manager. PMs who treat the Scrum Master as a coordinator for their own work create dysfunction. Their job is to protect the process and clear impediments, not to execute the PM’s list.
Your job in each ceremony
Five ceremonies, five distinct PM accountabilities:
- Sprint planning. You own the prep: groomed backlog, acceptance criteria written, Sprint Goal drafted before the room fills. Facilitate context, not discovery.
- Daily scrum. Listen for cross-boundary blockers; act outside the meeting. If it becomes a status update for you, surface that in the retro.
- Sprint review. You own this one. Treat it as a feedback loop with stakeholders and real users, not an internal demo. Close the gap between what shipped and what the market signal says, then update the backlog.
- Sprint retrospective. Attend as a participant. Leave with one concrete change to how the team works, or the ceremony is theater.
- Backlog refinement. Ongoing, not an event. This is where most of the PM’s day-to-day tactical work lives.
When to use scrum vs. kanban
Scrum fits when work is complex enough that planning more than a few weeks out would change based on what you learn. Kanban fits when work is a continuous flow of support, bugs, or ops with no natural sprint boundary. Scrumban is growing in 2026: sprint planning for features, kanban flow for bugs and ops, one shared WIP limit to keep support from drowning planned work.
Scrum in 2026
Two shifts. First, smaller pods (four to five people) now match the output of ten-person teams with AI-assisted development. A bad Sprint Goal wastes a group with far more throughput per person than before. The stakes per cycle are higher, not lower. Second, AI tooling is absorbing backlog coordination overhead (story generation, refinement triage), so the PM’s job shifts toward Sprint Goal quality rather than grooming volume. Scrum.org launched a Professional Scrum Product Owner AI Essentials course in January 2026, signaling AI literacy is now a formal scrum competency. Interviewers will ask whether you have used AI to support backlog refinement or prioritization decisions.
The scrum loop maps onto the central PM challenge: the Sprint Review is where you test viability and lovability every two weeks. Feasibility is mostly solved. Whether the increment is something people actually want is not. Treat the review as a discovery event and it earns its place in the process.
Weak vs. strong answer
weak
"Scrum is an agile framework where you work in sprints. The team has standups every day, and at the end of each sprint you demo what you built. There's a product owner who manages the backlog and a scrum master who runs the ceremonies." This treats scrum as ritual, conflates PM and PO, says nothing about what value the PM adds at each ceremony, and gives the interviewer nothing to probe.
strong
"Scrum is the framework I use when the work is complex enough that we cannot plan more than a few weeks out without learning something that changes the plan. The core loop: agree on a Sprint Goal, build toward it for two weeks, show real working software in the review, then step back in the retro to improve how we work, not just what we built. My job sits mostly in two places: keeping the backlog healthy so engineers are never blocked on what to build next, and running the Sprint Review as a feedback mechanism with stakeholders rather than a status update. Where I have seen it fail is when the Sprint Goal becomes 'finish the items on the list.' At that point you have turned it into micro-waterfall. When I am at a company with a mix of planned feature work and ongoing support load, I push for a Scrumban hybrid: sprint planning for product work, kanban flow for bugs and ops, with one shared WIP limit."