Q1: What is the difference between Agile and Waterfall?

Waterfall                    Agile
─────────────────────        ─────────────────────
Sequential phases            Iterative sprints
Requirements fixed upfront   Requirements evolve
Deliver at the end           Deliver incrementally
Change is expensive          Change is expected
Heavy documentation          Working software > docs
Testing after development    Testing every sprint
Client sees product late     Client feedback every sprint

When to use Waterfall:
- Fixed requirements (government contracts, compliance)
- Hardware projects
- Short, well-defined projects

When to use Agile:
- Evolving requirements (most software projects)
- Need early feedback
- Complex, long-term projects
- Startup/product development

In Indian IT:
- Service companies use both (client decides)
- Product companies are almost always Agile
- Government/BFSI projects often use Waterfall

Q2: Explain Scrum. What are the roles, events, and artifacts?

Scrum = Agile framework with fixed-length sprints (1-4 weeks)

Roles:
- Product Owner → defines WHAT to build (backlog priority)
- Scrum Master → ensures process, removes blockers
- Development Team → builds the product (self-organizing)

Events (ceremonies):
- Sprint Planning → what to build this sprint
- Daily Standup → 15 min: what I did, what I will do, blockers
- Sprint Review → demo to stakeholders
- Sprint Retrospective → what went well, what to improve

Artifacts:
- Product Backlog → prioritized list of all features
- Sprint Backlog → items selected for current sprint
- Increment → working product at end of sprint

Key metrics:
- Velocity → story points completed per sprint
- Burndown chart → work remaining vs time
- Sprint goal → one clear objective per sprint

Q3: What is the difference between Scrum and Kanban?

Scrum                        Kanban
─────────────────────        ─────────────────────
Fixed sprints (1-4 weeks)    Continuous flow
Defined roles (PO, SM)       No prescribed roles
Sprint planning required     No planning meetings
Velocity-based               WIP limits
Changes wait for next sprint Changes anytime
Burndown charts              Cumulative flow diagrams

When to use Scrum:
- New product development
- Teams that need structure
- When sprint cadence helps planning

When to use Kanban:
- Support/maintenance teams
- Continuous delivery
- Unpredictable work (bug fixes, ops)
- Teams already mature in Agile

Q4: How do you estimate project timelines?

Answer framework: Break the project into work packages (WBS), estimate each task using story points or hours, add buffer for unknowns (15-20%), and validate with the team. Common estimation techniques: Planning Poker (Agile), Three-Point Estimation (optimistic + pessimistic + most likely / 3), and historical velocity from past sprints.

Key insight: Never estimate alone. The team doing the work should estimate. Your job as PM is to facilitate estimation, not dictate it. And always communicate estimates as ranges, not fixed dates.

Q5: How do you handle scope creep?

What interviewers want: A structured approach, not “I say no to everything.”

Answer: 1) Document the change request formally. 2) Assess impact on timeline, budget, and resources. 3) Present trade-offs to stakeholders: “We can add this feature, but it will push delivery by 2 weeks or we drop feature X.” 4) Get written approval before proceeding. 5) Update the project plan and communicate to the team.

The key is not preventing all changes — it is managing them through a formal change control process so nothing slips in without impact assessment.

Q6: A critical team member leaves mid-project. What do you do?

Immediate actions: 1) Assess what knowledge they hold (bus factor). 2) Check documentation status. 3) Redistribute their tasks to existing team members. 4) Communicate impact to stakeholders with revised timeline if needed. 5) Start hiring/backfill process.

Prevention: Maintain documentation, ensure knowledge sharing (pair programming, code reviews), cross-train team members, and never let one person be the single point of failure for any critical component.

Q7: How do you identify and manage project risks?

Risk Management Process:

1. Identify → brainstorm risks with team
   - Technical: new technology, integration issues
   - Resource: key person leaving, skill gaps
   - External: vendor delays, regulatory changes
   - Schedule: underestimation, dependencies

2. Assess → probability × impact matrix
   High probability + High impact = Critical
   Low probability + High impact = Monitor closely
   High probability + Low impact = Mitigate
   Low probability + Low impact = Accept

3. Plan response:
   - Avoid: change plan to eliminate risk
   - Mitigate: reduce probability or impact
   - Transfer: insurance, outsource, SLAs
   - Accept: acknowledge and prepare contingency

4. Monitor → review risks every sprint/week
   - Update risk register
   - Track risk triggers
   - Escalate when needed

Q8: How do you handle a difficult stakeholder?

Answer framework: 1) Understand their concerns — often difficult behavior comes from unmet expectations or lack of visibility. 2) Increase communication frequency — weekly status updates, proactive escalation. 3) Set clear expectations early — define what “done” looks like, agree on scope. 4) Document everything — decisions, approvals, change requests. 5) Escalate through proper channels if behavior continues.

Never badmouth the stakeholder in the interview. Frame it as: “I had a stakeholder with strong opinions about the technical approach. I scheduled a dedicated session to understand their concerns, presented data to support our approach, and we reached a compromise that satisfied both sides.”

Q9: What project management tools have you used?

Common tools in Indian IT: Jira (most common for Agile), Azure DevOps (Microsoft shops), Trello (small teams), Asana (non-tech teams), MS Project (Waterfall/traditional), Confluence (documentation), Slack/Teams (communication). Know at least Jira well — it is the default in 80% of Indian IT companies.

Q10: How do you measure project success?

Key metrics: On-time delivery (schedule variance), on-budget delivery (cost variance), scope completion (planned vs delivered features), quality (defect density, customer-reported bugs), stakeholder satisfaction (NPS or feedback), and team health (velocity trend, burnout indicators).

A project delivered on time but with unhappy stakeholders is not successful. A project delivered late but with high customer satisfaction might be. Success is multi-dimensional — know which metrics matter for the specific context.