Interview Q&A

spect Scrum Kanban Extreme Programming

(XP)

Framework

Type

Prescriptive, timeboxed

(Sprints)

Flow-based,

continuous delivery

Engineering-focused

gile methodology

Roles PO, Scrum Master, Dev

Team

No defined roles Coach, Developer,

Customer (on-site)

Work

Planning

Sprint Backlog (2–4

weeks)

Continuous pull

from board

Iterations, similar to

Sprints

Change

Policy

No changes during a

Sprint

Changes allowed

nytime

Change-resistant within

iteration

Focus Delivery + team

process

Visualizing flow and

limiting WIP

Code quality and

engineering discipline

Practices Daily Scrum, Sprint

Planning, Review,

Retro

Visual board, WIP

limits, Cycle Time

Pair programming, TDD,

CI/CD, Refactoring

Example:

support team may prefer Kanban for flexibility, while a product dev team building new

features might favor Scrum or XP for structure and code quality practices.

Follow On:

Definition:

The Product Backlog is an ordered list of everything that might be needed in the product,

serving as the single source of work for the Scrum Team.

How to maintain it:

• Continuously refine items for clarity, detail, and priority.
• Regularly update it based on feedback, market changes, and stakeholder input.
• Collaborate with the team to ensure shared understanding.

Real-World Example:

For a streaming platform, the backlog might start with high-level features like “Watchlist” and

“User Reviews”. As sprints progress, these are broken down into more detailed items like

“Add to Watchlist Button” or “Review Moderation Rules”.

Purpose:

Sprint Planning sets the direction for the upcoming Sprint. The team collaboratively decides

what can be delivered and how the work will be accomplished.

Key outcomes:

• A clear Sprint Goal.
• A selected set of Product Backlog Items (PBIs) for the Sprint.
• A high-level plan for delivering those items.

Real-World Example:

In a team building a customer support chatbot, the Product Owner presents the most

valuable backlog items. The team discusses capacity and agrees to focus on implementing

“Chatbot FAQ logic” and “User intent recognition.” These become the Sprint backlog.

A Git tag marks specific points in a repository’s history — usually to label release versions

(like v1.0, v2.1, etc.). It’s like a snapshot that says, “this commit is stable and ready to

release.”

Types of tags:

• Lightweight tag: just a name for a commit.
• Annotated tag: includes metadata like the tagger’s name, date, and message.

Commands:

git tag -a v1.0 -m "Version 1.0 release"

git push origin v1.0

Real-world example:

fter testing your project, you tag the commit representing your first release with v1.0. This

helps other developers or CI/CD pipelines identify which version is live.

A branch in Git is like a separate line of development — a parallel universe for your code. It

llows you to work on new features, bug fixes, or experiments without affecting the main

codebase (usually called the main or master branch).

Why branches are useful:

They make collaboration easier by keeping each developer’s work isolated until it’s ready to

be merged back.

Real-world example:

Imagine your company website is live, but you need to add a “dark mode” feature. Instead

of editing the main code directly (which might break the live site), you create a new branch

called feature/dark-mode to work independently. Once it’s done and tested, you merge it

back into main.

Git is a distributed version control system (VCS) that allows multiple developers to work on

project without overwriting each other's work. It's designed to be fast, flexible, and

scalable, allowing developers to track changes in code and collaborate with ease.

In contrast, SVN (Subversion) is a centralized version control system. This means that SVN

has one central repository, and developers check out code to work locally. Git, on the other

hand, allows every developer to have their own full local repository, including the project’s

history. This makes Git faster and more reliable, especially in distributed teams.

Real-World Example:

If you were working on a website project with a team, using Git allows each developer to

clone the repository, make changes locally, and push their changes without disrupting others.

In SVN, the code is pulled from the central server, and only one developer can commit

changes at a time.

Answer: A distributed version control system (DVCS) for tracking changes in source code during software development.

What interviewers expect

• A clear definition tied to Version Control in Git & GitHub projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Git & GitHub application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Git & GitHub architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Answer: travel app team uses Value vs. Effort to prioritize. “In-app booking” has high value and moderate effort, while “Flight status tracking” has high effort and low impact — so the former gets scheduled first.

What interviewers expect

• A clear definition tied to Agile in Agile & Scrum projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Agile & Scrum application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Agile & Scrum architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

Definition:

The Definition of Done is a shared understanding of what “done” means for a backlog item

or Increment. It ensures transparency and consistent quality.

Impact on quality:

• Prevents incomplete work from being marked as finished.
• Reduces rework by setting clear expectations.
• Ensures the Increment is potentially shippable.

Example DoD:

• Code is committed and peer-reviewed
• Unit tests are written and passed
• Integrated into CI/CD pipeline
• User story accepted by Product Owner
• No major bugs in QA

Real-World Example:

Without a DoD, a team may claim a feature is “done” even though it hasn’t been tested.

With a proper DoD, it won’t be considered complete until it’s fully tested, reviewed, and

accepted.

Follow On:

Sprint is a fixed-length (usually 1–4 weeks) timebox where a usable and potentially

shippable product increment is developed. The Sprint fosters focus, regular delivery, and

continuous improvement.

Example:

digital agency might run 2-week Sprints to deliver iterative updates to a client’s website.

fter each Sprint, the client gets a working piece — such as a new landing page — and

provides feedback that shapes the next Sprint.

Scrum-of-Scrums (SoS) is a coordination mechanism where representatives from multiple

Scrum teams meet regularly to discuss progress, dependencies, and blockers.

Structure:

• Each team sends a delegate (often the Scrum Master or a dev lead).
• Frequency varies (e.g., 2–3 times/week).
• Focus is on cross-team coordination, not status reporting.

Example agenda:

• What has your team completed?
• What will your team work on next?
• Are there any blockers or dependencies?

Example:

In a bank's digital transformation project, five Scrum teams are building different modules of

the same app. SoS meetings align delivery and resolve integration issues early.

The Product Owner:

• Continuously refines the Product Backlog — even during a Sprint.
• Works with stakeholders and the team to break down large items.
• Clarifies acceptance criteria.
• Re-prioritizes based on new insights.

Example:

Mid-Sprint, the PO learns from sales that customers are struggling with onboarding. They

update the backlog by splitting “User Onboarding Flow” into smaller, clearer stories for the

next Sprint.

spect Scrum Traditional (Waterfall)

Process Style Iterative and incremental Sequential and linear

Requirements Evolve over time Defined upfront

Follow On:

Team Involvement Cross-functional, collaborative Role-specific, hierarchical

Flexibility to Change High — welcomes changes Low — changes can be

costly

Delivery Frequent, every Sprint At the end of the project

Example:

In traditional construction, everything is planned before a brick is laid. In Scrum, like in

software development, teams build part of the system, get feedback, and adapt — like

dding a new feature based on early user testing.

Purpose:

The Sprint Goal provides focus and alignment for the team. It serves as a shared

objective for the Sprint, guiding decisions and trade-offs.

Defining a good Sprint Goal:

• Collaboratively set during Sprint Planning.
• Clear, concise, and focused on outcome, not just output.
• Tied to business or customer value.

Example:

Instead of “build three reports,” a better Sprint Goal would be:

✅ “Enable users to access key sales insights through interactive reports.”

spect Product Backlog Sprint Backlog

Follow On:

Owner Product Owner Development Team

Scope All desired features, bugs,

enhancements

Items selected for current Sprint

Timefram

Long-term, evolves continuously Short-term, Sprint-specific

Content Prioritized list of user

stories/features

Detailed tasks and plan for delivering

them

Example:

The Product Backlog includes “User Profile Page”, “Email Notifications”, “2FA Setup”. For

Sprint 4, the team selects “Email Notifications” and breaks it into tasks like “Create email

template”, “Setup backend service”, etc., forming the Sprint Backlog.

Product Owner Team is a group of Product Owners (or PO + Product Managers) who

collaboratively manage a complex or large product backlog.

You need it when:

Follow On:

• The product is large or has multiple subcomponents.
• Multiple Scrum teams work on shared features or user journeys.
• Work spans multiple markets, compliance zones, or personas.

Structure:

• Chief Product Owner (overarching vision)
• POs for feature areas or team-specific backlogs
• Shared roadmap and prioritization process

Example:

For an enterprise SaaS platform with HR, Finance, and Compliance modules, each module

has a dedicated PO, coordinated by a Chief PO.

User Story describes a feature from the end-user’s perspective. It answers: Who wants

it? What do they want? Why do they want it?

Template:

s a [type of user], I want [some goal], so that [some reason].

Best practices:

• Add Acceptance Criteria to clarify expectations.
• Keep it concise, focused, and testable.

Follow On:

Example:

s a shopper, I want to filter products by price range, so I can find items within

my budget.

cceptance Criteria:

• Price slider from $0–$500
• Real-time update of results
• Works on mobile and desktop

Definition:

A Product Owner Team is a group of Product Owners (or PO + Product Managers) who

collaboratively manage a complex or large product backlog.

You need it when:

Follow On:

• The product is large or has multiple subcomponents.
• Multiple Scrum teams work on shared features or user journeys.
• Work spans multiple markets, compliance zones, or personas.

Structure:

• Chief Product Owner (overarching vision)
• POs for feature areas or team-specific backlogs
• Shared roadmap and prioritization process

Example:

For an enterprise SaaS platform with HR, Finance, and Compliance modules, each module

has a dedicated PO, coordinated by a Chief PO.

Definition:

A User Story describes a feature from the end-user’s perspective. It answers: Who wants

it? What do they want? Why do they want it?

Template:

As a [type of user], I want [some goal], so that [some reason].

Best practices:

• Add Acceptance Criteria to clarify expectations.
• Keep it concise, focused, and testable.

Follow On:

Example:

As a shopper, I want to filter products by price range, so I can find items within

my budget.

Acceptance Criteria:

• Price slider from $0–$500
• Real-time update of results
• Works on mobile and desktop

The Scrum Master facilitates, coaches, and removes obstacles. Unlike a traditional project

manager, they don’t assign tasks or manage timelines.

Scrum Master Project Manager

Facilitates Scrum practices Manages scope, schedule, and

budget

Focuses on team dynamics and

coaching

Focuses on deliverables and

deadlines

Servant leader Authority figure

Example:

If a developer is stuck due to a permissions issue, the Scrum Master will help resolve it. A

project manager might instead adjust timelines or escalate to keep the schedule on track.

The Product Owner (PO) is the voice of the customer and is responsible for:

• Defining and prioritizing the Product Backlog.
• Maximizing value delivered by the team.
• Making trade-off decisions between features, cost, and time.

Example:

In a fintech app team, the PO decides that user onboarding is more critical than the referral

program, so it’s prioritized in the backlog. This ensures the team focuses on what's most

valuable for launch.

Follow On:

Answer: team working on a healthcare dashboard decides among themselves who takes on UI, backend, and testing tasks — without needing direction from a manager — and ensures the code is production-ready by Sprint’s end.

What interviewers expect

• A clear definition tied to Agile in Agile & Scrum projects
• Trade-offs (performance, maintainability, security, cost)
• When you would and would not use it in production

Real-world example

In a production Agile & Scrum application, teams apply this when handling user-facing features or integration boundaries. For example, you might use it during a sprint where reliability and observability matter—logging metrics, validating edge cases, and documenting the decision in an ADR so future developers understand why the approach was chosen.

How to explain in the interview

1. Define the concept in one or two sentences.
2. Context — where it fits in Agile & Scrum architecture.
3. Example — a specific project, bug, or performance win.
4. Trade-off — what you gain vs what you sacrifice.

Tip: Practice aloud on Toolliyo mock interview or the Interview Q&A section before your real interview.

The Development Team is responsible for:

• Delivering a potentially shippable increment at the end of each Sprint.
• Self-organizing how they accomplish the work.
• Collaborating closely and maintaining quality.

Example:

A team working on a healthcare dashboard decides among themselves who takes on UI,

backend, and testing tasks — without needing direction from a manager — and ensures the

code is production-ready by Sprint’s end.

Burndown Chart is a visual tool that shows the remaining work in a Sprint or project

over time.

Purpose:

• Helps teams monitor progress toward completing the Sprint backlog.
• Enables early identification of scope creep or falling behind.

Follow On:

How to use:

• X-axis: Days in Sprint
• Y-axis: Remaining effort (usually in story points or hours)
• Ideal line vs. actual line

Example:

Midway through a Sprint, a team sees the burndown flatlining (no work is getting “done”).

This prompts a conversation — they discover a blocker in API access and address it before

the Sprint is derailed.

Scrum Implementation & Best

Practices:

Definition:

A Burndown Chart is a visual tool that shows the remaining work in a Sprint or project

over time.

Purpose:

• Helps teams monitor progress toward completing the Sprint backlog.
• Enables early identification of scope creep or falling behind.

Follow On:

How to use:

• X-axis: Days in Sprint
• Y-axis: Remaining effort (usually in story points or hours)
• Ideal line vs. actual line

Example:

Midway through a Sprint, a team sees the burndown flatlining (no work is getting “done”).

This prompts a conversation — they discover a blocker in API access and address it before

the Sprint is derailed.

Scrum Implementation & Best

Practices: