Agile & Scrum

1. What are the four values of the Agile Manifesto?

The Agile Manifesto, written in 2001, states four value preferences. They are:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

The important nuance is the “over” — the manifesto does not say the right-hand items are worthless. Processes, documentation, contracts, and plans all have value. The point is that when the two sides conflict, the left side wins.

So a team should favor people talking directly over rigid process rituals, deliver working software over endless spec documents, work with the customer as a partner rather than negotiating against them, and welcome change rather than defending a frozen plan. These values are the philosophical foundation — the twelve principles are practical implications drawn from them.

2. What are the principles of Agile?

The Agile Manifesto is backed by twelve principles that translate the four values into working practices. The ones worth knowing cold:

Deliver working software frequently, with a preference for the shortest feasible time span — weeks, not months. Welcome changing requirements, even late in development, and treat them as a competitive advantage. Deliver working software as the primary measure of progress — demos beat status reports. Business people and developers must work together daily throughout the project.

Build projects around motivated individuals, give them the environment and support they need, and trust them. The most efficient communication is face-to-face conversation. Working software is the measure of progress. Agile processes promote sustainable development — the team should be able to maintain a constant, healthy pace indefinitely. Attention to technical excellence and good design enhances agility.

Simplicity — maximizing the amount of work not done — is essential. The best architectures, requirements, and designs emerge from self-organizing teams. And at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

3. What is a user story?

A user story is a short, plain-language description of a feature written from the end user’s perspective. It captures what the user wants and why, in a form small enough to be planned into a sprint.

The classic format is “As a [role], I want [action], so that [benefit].” For example, “As a customer, I want to track my order, so that I know when it will arrive.” The role gives the context, the action gives the functionality, and the benefit explains the value.

A good story follows the INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, and Testable. Critically, the story is a placeholder for conversation — it is deliberately brief, and the details are worked out in discussion between the team and the product owner. Its acceptance criteria make it testable. Stories sit in the product backlog, get refined, and are pulled into sprints, usually split down until each is small enough to finish in a sprint.

4. What are acceptance criteria?

Acceptance criteria are the concrete conditions a user story must satisfy for it to be considered done and acceptable to the product owner. They define “what does done look like” for that specific story, in testable terms.

They are usually written as a checklist of Given/When/Then scenarios in Behavior-Driven Development style, or as a simple list of conditions. For example, for “customer tracks order”: “Given an order has shipped, when the customer checks status, then they see an estimated delivery date.” Each criterion is a test the story must pass.

Acceptance criteria serve three purposes. They make the story testable — the team and tester know exactly what to verify. They remove ambiguity — both sides agree on the definition of the feature before it is built. And they anchor the acceptance testing — the customer validates the delivered story against these criteria in the sprint review. Stories without acceptance criteria are a guessing game; stories with them are contracts.

5. What is a product backlog?

The product backlog is the single, prioritized list of everything that might go into the product — features, fixes, improvements, technical work, and user stories. It is the team’s source of all work, owned by the product owner.

Items in the backlog are ordered by priority, with the most valuable and urgent at the top. Top items are small, detailed, and “ready” for a sprint; lower items are larger and sketchier — often called epics — and get refined and broken down as they approach the top. The backlog is never frozen: it grows as new ideas, feedback, and market changes arrive, and items get reprioritized continuously.

The backlog is dynamic — it is a living list, not a contract. The product owner adds, reorders, and removes items based on value, and the team helps estimate and refine. This is the mechanism that makes Agile’s “respond to change” concrete: a new requirement is not a crisis, it is a new backlog item that gets prioritized like any other.

6. What is a sprint backlog?

The sprint backlog is the subset of the product backlog that the team commits to completing during the current sprint. It contains the user stories selected for the sprint plus the tasks needed to implement them.

The sprint backlog is created during sprint planning, when the team picks the top stories it can finish and breaks them into concrete tasks — coding, testing, designing, reviewing. It is owned by the team, not the product owner: once the sprint starts, the team decides how to execute it. The team updates the backlog daily during the standup, tracking progress through the tasks.

It is essentially the team’s plan for the sprint, visible to everyone. The key discipline is that the sprint backlog is fixed in scope — the goal is agreed, and items are not swapped mid-sprint. If the team discovers new work, it replaces other work or spills over; it does not silently grow the backlog. The sprint backlog makes the sprint’s commitment concrete and trackable.

7. What is backlog refinement?

Backlog refinement — also called backlog grooming — is the ongoing activity of keeping the product backlog in good shape: adding detail, breaking down large items, re-estimating, re-prioritizing, and removing obsolete entries.

It is not sprint planning — it happens between sprints, continuously. During refinement, the team and product owner look ahead at the upcoming items and prepare them so they are “ready” to be pulled into a sprint: big epics are split into stories, vague items get their acceptance criteria written, and estimates are updated as understanding grows.

Refinement serves two goals. It keeps the backlog honest — the top of the backlog always contains items that are small, clear, and estimable. And it reduces planning friction — when sprint planning arrives, the team is not trying to understand fuzzy requirements on the spot. A good rule of thumb is that a team spends about 10% of its capacity on refinement, continuously preparing work a sprint or two ahead.

8. What happens during Sprint Planning?

Sprint planning is the meeting at the start of a sprint where the team decides what it will build and how. It has two parts: what and how.

In the “what” part, the team and product owner review the top of the product backlog, and the team selects the stories it commits to delivering in the sprint. The product owner sets the sprint goal — the business objective the sprint will achieve — and the team picks the backlog items that serve it. In the “how” part, the team decomposes the selected stories into concrete tasks and estimates them, so everyone leaves with a clear picture of the work and the sprint backlog is built.

The output of sprint planning is three things: a sprint goal, a sprint backlog of selected stories with tasks, and a shared confidence that the team can complete the commitment. For a two-week sprint, planning typically takes a few hours. The team does all the estimation — the product owner does not assign or dictate work.

9. What happens during a Sprint Review?

The sprint review is the meeting at the end of a sprint where the team demonstrates what it built and the stakeholders react to it. It is a working session to inspect the increment and adapt the product backlog.

The team demos the completed stories against their acceptance criteria — not slides, but working software. Stakeholders — the product owner, customers, and other interested parties — give feedback: what they like, what they want changed, what is missing. The product owner decides whether each story is accepted, and unfinished or rejected stories go back to the product backlog.

The review ends with an updated backlog: new insights become new items, priorities shift, and the product owner reprioritizes for the next sprint. The sprint review is about the product — is the team building the right thing? — while the retrospective is about the process — how well did the team work together? They are often confused, but they answer different questions.

10. What happens during a Sprint Retrospective?

The sprint retrospective is the meeting after the sprint review where the team examines its own process and decides how to improve. It answers the question: “how did the sprint go, and what should we change?”

The team discusses three things: what went well, what went wrong, and what could be improved. Common formats guide the conversation — Start/Stop/Continue, what went well/what didn’t, or a timeline of the sprint. The output is a small set of concrete, actionable improvements the team commits to trying in the next sprint, not a list of complaints.

The retrospective is private to the team — no managers or product owners judging — so people can be honest. It is also the mechanism for continuous improvement, one of the twelve Agile principles: regularly reflect on becoming more effective, then tune and adjust. A retrospective that produces no action items is a wasted meeting; the value is in the commitments the team actually implements.

11. What is the purpose of the Daily Scrum?

The Daily Scrum — the daily standup — is a short, time-boxed meeting, typically 15 minutes, held at the same time every day. Its purpose is to synchronize the team and plan the day’s work, not to give a detailed status report to a manager.

Each team member answers three questions: What did I do yesterday? What will I do today? What is blocking me? The point is to surface impediments early, so the team and Scrum Master can act on them, and to keep everyone aligned on progress toward the sprint goal.

The Daily Scrum is for the team, not management — it is the developers’ opportunity to adjust their plan for the day. Detailed problem-solving is explicitly deferred to follow-up conversations after the meeting, so the standup stays short. In practice, teams often stand around a board or track tasks digitally. The value is daily alignment and early detection of blockers, which keeps the sprint moving.

12. What is Definition of Done?

Definition of Done (DoD) is the shared agreement on what “finished” means for a product backlog item. It is a checklist of quality conditions that every completed story must meet before it can be called done — different from acceptance criteria, which are specific to each story.

A typical DoD includes: code written, unit tests passing, code reviewed, integrated with the rest of the system, documented, and deployable. Exactly what belongs in the DoD is set by the team and may vary by organization — a team that does production releases every sprint has a stricter DoD than one that releases quarterly.

The DoD protects quality from being negotiated away. Without it, “done” means different things to different people — a developer might call code written “done” while the tester is still waiting to test it. The DoD is universal: it applies to every item, whether a story, a bug fix, or a technical task. When an item does not meet the DoD, it goes back — it is not done.

13. What is Definition of Ready?

Definition of Ready (DoR) is the shared agreement on when a product backlog item is ready to be pulled into a sprint. It is the flip side of Definition of Done — DoD defines when work is finished; DoR defines when work can be started.

A typical DoR includes: the story has clear acceptance criteria, it is estimated, it is small enough to fit in a sprint, dependencies are identified, and the team understands it well enough to commit to it. Items that do not meet the DoR are not taken into a sprint — they stay in the backlog and get refined further.

The purpose is to prevent planning disasters. A story pulled into sprint planning that is vague, unestimated, or too large derails the commitment — the team cannot estimate, plan, or commit to it. The DoR, maintained through backlog refinement, keeps the top of the backlog always ready for the sprint. Like the DoD, it is set by the team and refined over time as the team learns what “ready” really requires.

14. What are story points?

Story points are a relative measure of the size of a user story — its effort, complexity, and uncertainty combined. They are used instead of hours because the point is to compare stories to each other, not to predict exact time.

The team assigns points on a scale, commonly a modified Fibonacci sequence — 1, 2, 3, 5, 8, 13, 21 — because the gaps widen as size grows, reflecting how estimates become less precise for bigger items. A 5-point story is not five times a 1-point story in hours; it is simply larger by a known relative amount. Points are assigned by the whole team through planning poker, where members vote and discuss until they converge.

Points deliberately exclude personal speed — they measure the story, not the developer, so a 5 is a 5 whether a senior or a junior does it. The team’s velocity then converts points into schedule. Story points are stable and comparative, which makes planning possible without pretending to know exact hours.

15. How does Agile estimation work?

Agile estimation is relative and team-based. The team compares each item to items it already knows, rather than predicting absolute hours, and the whole team contributes through a structured technique.

The standard technique is planning poker. Each team member gets a set of cards with values from the modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 21). For each story, members privately pick a card, reveal simultaneously, and then discuss — especially where estimates diverge. The discussion surfaces hidden complexity, risks, or misunderstandings. After discussion, they re-vote until they converge, and the final agreed value becomes the story’s estimate.

Estimation is not done once. As understanding grows, estimates are refined, and large stories are split into smaller ones. The team estimates in story points, then uses velocity — points completed per sprint — to forecast how much work fits in future sprints. The estimates are inputs to planning, not commitments to the hour — the team gets better at forecasting with practice.

16. What is velocity in Scrum?

Velocity is the measure of how much work a Scrum team completes per sprint, expressed in story points. It is the team’s throughput — the total points of work that finished in a sprint, by the team’s Definition of Done.

Velocity is used for forecasting: if a team’s average velocity is 30 points per sprint, the product owner can predict that a 90-point backlog will take roughly three sprints. It lets the team plan realistic sprint commitments — pick items whose total points match the running velocity.

Velocity is team-specific and not comparable across teams — a team that calls a task 5 points may finish more actual work than a team where that same task is 8 points, because estimates are relative to each team’s scale. Velocity is also not a performance score to be maximized; it is a planning tool. It fluctuates with team size, context switching, and quality issues, so teams use a rolling average rather than a single sprint’s number. It is only meaningful against the team’s own Definition of Done.

17. How is velocity calculated?

Velocity is calculated by summing the story points of all product backlog items that were completed during the sprint — completed meaning they meet the team’s Definition of Done.

For example, if a team finishes a 5-point story, a 3-point story, and two 8-point stories in a sprint, the velocity is 24 points. Partially completed items do not count, and points for items that were started but not finished are not credited. This rule keeps velocity honest — it measures delivered value, not effort spent.

For planning, the team uses a rolling average of recent sprints — say the last three to five — because single-sprint velocity fluctuates with context switching, team availability, and unexpected work. The average then drives forecasting: average velocity per sprint divided into the remaining backlog gives the projected completion time. The more sprints the average covers, the more reliable the forecast.

18. What is a burndown chart?

A burndown chart is a graph that tracks remaining work in a sprint over time. The x-axis is the sprint’s days, and the y-axis is the amount of work remaining, usually in story points. As the team completes items, the line falls toward zero.

The chart also typically shows a diagonal “ideal” line representing perfect, linear progress. By comparing the actual burndown line to the ideal line, the team sees at a glance whether it is ahead of or behind schedule — and, critically, whether the sprint goal is in danger.

The burndown chart is a communication tool, not a weapon. A line above the ideal means work is going slower than planned; the team then adjusts — reprioritizing, removing scope, or working faster — rather than just watching it fail. There are also release burndown charts tracking remaining work across multiple sprints. The value is simple: one glance shows whether the sprint is on track or needs attention.

19. What is a burnup chart?

A burnup chart tracks completed work over time, but unlike a burndown chart it shows two lines: the total scope and the work completed. The x-axis is time and the y-axis is story points or features.

The completed line rises as work gets done, and the scope line shows the total amount of work — which can move, because scope can grow. When the completed line catches the scope line, the project or release is done. The gap between the lines is the remaining work.

The burnup chart’s advantage over the burndown is that it makes scope changes visible. On a burndown chart, if new work is added, the remaining-work line can rise or flatten confusingly — the chart looks like the team is failing. A burnup chart shows the completed line steadily rising while the scope line rises too, revealing honestly that scope grew. It answers two questions at once: how much is done, and how big is the target. It is clearer for long projects where scope changes are expected.

20. How does a Scrum Master handle impediments?

The Scrum Master’s job is to remove obstacles that block the team from making progress. When an impediment is surfaced — in the Daily Scrum, in a retrospective, or anywhere else — the Scrum Master first understands it and assesses whether it can be resolved by the team itself or needs help.

The Scrum Master then works to remove it: clearing a blocked environment, escalating a dependency to a stakeholder, resolving a resource conflict, or helping the team work around a technical blocker. Anything the team can solve itself stays with the team; the Scrum Master focuses on what is outside the team’s control.

The Scrum Master tracks impediments transparently, often on a visible list, so nothing is silently forgotten. They also look for patterns — if the same blocker keeps recurring, the root cause needs fixing, not just the symptom. Impediment removal is a continuous activity, not a sprint-end event. The measure of success is that the team can deliver steadily because obstacles are removed quickly and permanently.

21. What happens when a Sprint goal cannot be achieved?

When a Sprint goal cannot be achieved, the Scrum Master and team have options — they are not forced to fail silently. The first step is to acknowledge it early, using the daily standup and burndown chart, rather than discovering it on the last day.

The team can negotiate scope: if the goal can still be met with a subset of the work, the team and product owner agree to drop lower-priority items. In Scrum, the product owner can cancel the sprint if the goal has become obsolete — for example, the market moved or a dependency changed. Cancellation stops the sprint, and completed work is reviewed; what was done goes back or is released, and the team re-plans.

Ideally, the goal is protected: a good sprint goal is achievable, and if it becomes unreachable the team surfaces it immediately, so the product owner can decide between reducing scope, extending the sprint (rare), or cancelling. The worst outcome is hiding the problem until the review. Honest, early escalation turns an unreachable goal into a managed decision.

22. How are changing requirements handled during a Sprint?

Once a sprint starts, the sprint backlog is frozen in scope — the team commits to the selected items and the product owner should not pull work in or out. This is the core of sprint focus: stability for the team so it can deliver its commitment.

That does not mean new requirements are ignored — they are simply queued. A new request during a sprint goes to the product owner, who adds it to the product backlog and prioritizes it. It is considered for the current sprint only in exceptional cases: the product owner can cancel the sprint if the change makes the current goal obsolete, or the team and product owner can agree to swap an item of equal size — though this is discouraged.

The disciplined answer is: new requirements enter the backlog, not the sprint. The team finishes what it committed to, and the new work is planned into the next sprint based on priority. This protects both the team’s focus and the predictability of delivery, while still embracing change — just at the sprint boundary, where it can be planned properly.

23. What is the difference between Scrum and Kanban?

Scrum and Kanban are both Agile frameworks, but they differ in structure. Scrum works in fixed-length sprints — time-boxed iterations of two to four weeks — with a planned goal, and roles (Product Owner, Scrum Master, Developers) and ceremonies (planning, daily standup, review, retrospective). Work is committed to for the sprint; change waits for the next sprint.

Kanban has no iterations at all. It is a continuous flow system based on a visual board with columns and work-in-progress (WIP) limits. Work is pulled through as capacity frees up, and items can be added or reprioritized at any time. There are no sprints, no fixed roles, and no prescribed ceremonies.

The choosing question is how work arrives. If the team has regular, deliverable-sized work that benefits from iteration — Scrum gives rhythm, goals, and inspection points. If work is continuous and unpredictable — operations, support tickets, maintenance — Kanban’s continuous flow fits better. Many teams combine them: the planning and review cadence of Scrum with the flow limits of Kanban.

24. What is the difference between Agile and Scrum?

Agile is a philosophy; Scrum is a framework that implements it. Agile is a set of values and principles — the Agile Manifesto’s four values and twelve principles — that describe a mindset: iterative delivery, customer collaboration, responding to change. Agile itself prescribes no roles, meetings, or artifacts.

Scrum is one specific way of applying that mindset. It prescribes concrete structures: the Product Owner, Scrum Master, and Developers roles; the Product Backlog, Sprint Backlog, and Increment artifacts; and the Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective ceremonies.

So Scrum is Agile, but Agile is not Scrum. Kanban, Extreme Programming (XP), and Lean are other Agile frameworks. Choosing Scrum means committing to its ceremonies and roles; choosing Agile means adopting the mindset, which any framework can serve. An interview trap to avoid: saying Scrum and Agile are the same thing. Agile is the umbrella, Scrum is one of the umbrellas.