Interview Ready Questionnaire 1. Core Agile Concepts What is Agile project management, and how is it different from traditional (waterfall) project management?  Agile is an iterative approach where work is delivered in small increments (sprints), with frequent feedback and adaptation.  Agile embraces changing requirements and continuous delivery.  Waterfall is linear: requirements → design → build → test → release, with changes harder and later.  Waterfall assumes stable requirements up front. What are the four values of the Agile Manifesto?  Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan  You still use processes, docs, contracts, and plans—but you prioritize the left side. What are the 12 Agile principles (in spirit)? Key ideas:  Satisfy customers with early and continuous delivery of valuable software.  Welcome changing requirements, even late.  Deliver working software frequently (weeks, not months).  Business people and developers must collaborate daily.  Build projects around motivated individuals; trust them.  Face-to-face (direct) conversation is most effective.  Working software is the primary measure of progress.  Promote sustainable pace; avoid burnout.  Continuous attention to technical excellence and good design.  Simplicity—maximize work not done.  Best architectures/requirements emerge from self-organizing teams.  Reflect regularly and tune behavior. When would you choose Agile over waterfall, and when might you blend both?  Use Agile when requirements are uncertain, the environment changes quickly, and you need fast feedback (e.g., product features, digital products).  Use waterfall when requirements are stable, regulated, and changes are costly (e.g., hardware, some compliance-heavy projects).  In practice, many teams blend: Agile for delivery, waterfall-style governance for milestones, budgets, or regulatory checkpoints.

2. Scrum Framework Basics What is Scrum, and how does it relate to Agile?  Scrum is a lightweight Agile framework for managing complex work. It implements Agile principles through specific roles, events, artifacts, and rules, using short time-boxed sprints to deliver increments of value. What are the three pillars of Scrum?  Transparency: Work and progress are visible to all.  Inspection: Frequent checks on progress and artifacts.  Adaptation: Adjusting process or product based on what you learn. What are the Scrum values?  Commitment  Courage  Focus  Openness  Respect These guide how the team behaves and makes decisions. Describe the three Scrum roles.  Product Owner: Owns the product backlog, prioritizes by value, represents stakeholders/customers.  Scrum Master: Coaches the team on Scrum, removes impediments, facilitates events.  Developers (Development Team): Cross-functional people who do the actual work to deliver the increment. What does each role do day-to-day?  Product Owner: Refines backlog, clarifies requirements, accepts/rejects work, aligns with stakeholders.  Scrum Master: Facilitates ceremonies, helps remove blockers, coaches on Agile practices.  Developers: Design, build, test, and deliver increments; collaborate daily in stand-ups. 3. Scrum Artifacts What is a product backlog? Who owns it, and how is it maintained?  A prioritized list of everything that might be needed in the product (features, bugs, tech debt).  Owned by the Product Owner, who continuously refines it with input from the team and stakeholders, splitting and reordering items as learning evolves. What is a sprint backlog? How is it created?  The set of product backlog items selected for the sprint, plus a plan for delivering them.  Created in sprint planning by the Developers, who break items into tasks and commit to a realistic scope.

What is an increment? What does “Done” mean in your team?  An increment is the sum of all completed backlog items at the end of a sprint, integrated and potentially shippable.  “Done” is a shared definition (DoD) that specifies quality criteria (coded, tested, documented, integrated, etc.) that must be met before something is considered complete. How do you ensure the backlog is refined and ready for upcoming sprints?  Regular backlog refinement sessions with PO and team: clarify acceptance criteria, split large items, estimate effort, and reorder by value/risk so top items are “ready” for the next sprint. 4. Scrum Events (Ceremonies) Sprint planning – goal, attendees, inputs/outputs, how do you decide what goes in?  Goal: Agree on the sprint goal and what can be delivered.  Attendees: Scrum Team (Product Owner, Scrum Master, Developers).  Inputs: prioritized backlog, team capacity, past velocity.  Outputs: sprint goal, sprint backlog, plan. You select items from the top of the backlog that fit capacity and align to the sprint goal. Daily stand-up – purpose, format, anti-patterns?  Purpose: Inspect progress toward the sprint goal and adapt the plan for the next 24 hours.  Format: 15-minute time-box; each developer shares what they did, what they’ll do, and blockers.  Anti-patterns: turning it into a status report to the manager, problem-solving long discussions, or skipping it when busy. Sprint review – what happens, who attends, how is feedback used?  Review the increment with stakeholders; demo working functionality; gather feedback to adapt the backlog.  Attendees: Scrum Team + key stakeholders.  Feedback may lead to new items, reprioritization, or scope changes in future sprints. Sprint retrospective – goal, typical activities, examples of improvements?  Goal: Inspect how the last sprint went and identify improvements.  Activities: Discuss what went well, what didn’t, and agree on 1–3 actionable changes (e.g., limit WIP, improve DoD, adjust stand-up format).  Example improvements: Better refinement, clearer acceptance criteria, reducing context switching. Backlog refinement – how often, what does a “good” refined story look like?  Usually once or twice per sprint, as needed.  A good refined story is clear, small enough to fit in a sprint, has acceptance criteria, is understood by the team, and is estimated.

5. Metrics and Tracking What is velocity, and how do you use it (and not misuse it)?  Velocity is the average amount of work (often story points) a team completes per sprint, used for forecasting future capacity.  Use it to plan realistic sprints and releases; don’t use it to compare teams or as a performance target, or it becomes a vanity metric. How do you read and use a burndown chart?  A burndown shows remaining work vs time in a sprint. Ideal line slopes down to zero by sprint end. If actual line is above ideal, you’re behind; if below, ahead.  Use it to spot risks early (scope added, slow progress) and adjust plan or scope. What is a burnup chart, and when might you prefer it?  A burnup shows total scope and completed work over time.  It’s better when scope changes frequently, because you can see both progress and scope growth, whereas burndown can be confusing when scope increases. How do you track progress within a sprint without micromanaging?  Rely on the sprint backlog, daily stand-ups, and visible boards (Kanban/Jira).  Focus on blockers and flow, not individual task policing.  Use metrics like burndown and cumulative flow to see trends, not to judge individuals. 6. Working with stakeholders and teams How do you manage changing requirements mid-sprint?  Protect the sprint goal.  If a change is critical, discuss with PO and team: either swap out equivalent work or defer to next sprint.  Avoid frequent mid-sprint scope changes; instead, capture new needs in the backlog for prioritization. How do you handle a stakeholder who keeps adding “urgent” items?  Acknowledge urgency, but route everything through the PO and backlog.  Work with PO to prioritize based on value and impact.  If truly urgent, negotiate what comes out of the current sprint or plan it into the next one. How do you say no or negotiate scope while staying Agile? Frame it around capacity and value: “Given our velocity and sprint goal, taking this in now means dropping X or risking quality. Let’s prioritize with the PO and schedule what delivers the most value soonest.” How do you coach a team or stakeholder new to Agile/Scrum?  Start with why (benefits of iterative delivery and feedback), then walk through roles, events, and artifacts with concrete examples.  Run good ceremonies, show early wins, and gradually deepen practices (refinement, DoD, metrics).

7. Practical scenario questions (sample answers) Tell me about a time a sprint was at risk of missing its goal. What did you do? Example structure:  Situation: Mid-sprint, key dependency delayed; burndown flat for 3 days.  Action: Raised in stand-up, worked with PO to de-scope lower-priority items, re-planned tasks, paired developers to unblock critical work, updated stakeholders on revised scope.  Result: Delivered core sprint goal on time, moved lower-priority items to next sprint, team learned to flag risks earlier. Describe a time you improved your team’s process based on a retrospective. Example:  Issue: Stand-ups were long and unfocused.  Change: Time-boxed to 15 minutes, focused on sprint goal and blockers, moved detailed discussions offline.  Result: Shorter stand-ups, faster issue resolution, better flow. How do you handle a team member who consistently misses commitments?  Have a private conversation to understand root causes (skill gap, overload, personal issues).  Adjust workload, provide support or pairing, and set clear expectations.  If it continues, escalate per company process while staying supportive. How do you run a sprint when requirements are unclear or keep changing?  Invest more in refinement: collaborate with PO to clarify acceptance criteria, split into smaller experiments, use time-boxed spikes to reduce uncertainty, and keep sprint goals narrow and flexible. How do you balance tech debt vs new features in sprint planning?  Work with Product Owner and Tech Lead to make tech debt visible in the backlog, estimate it, and negotiate a capacity split (e.g., 70% features, 30% debt/improvements).  Tie tech debt to risk, performance, or future velocity to show value. 8. TPM-specific angles How do you work with engineering leads on sprint planning and capacity?  Partner with engineering leads to understand capacity (holidays, on-call, meetings), align on priorities, and ensure the plan is realistic.  Use their input to shape the sprint goal and commit only to what the team can deliver. How do you incorporate non-functional work (infra, security, reliability) into sprints?  Treat them as backlog items with clear value/risk, estimate and prioritize like features.  Ensure some capacity each sprint for reliability/security work, especially if there are SLAs or compliance needs. How do you coordinate multiple teams or dependencies across sprints?  Use shared roadmaps, dependency boards, and regular syncs (Scrum of Scrums or similar).

 Align sprint start/end dates where possible, and track cross-team dependencies explicitly in planning. How do you use tools like Jira/Confluence to manage backlogs and sprints?  Jira: Maintain prioritized backlog, plan sprints, track tasks, visualize burndown/velocity.  Confluence: Document DoD, working agreements, sprint goals, and key decisions.  Keep both up to date so status is transparent.