81. What is Extreme Programming (XP) in Agile software development?
- An extreme version of traditional programming where developers work 24 hours a day
- An Agile software development methodology that emphasizes technical excellence through practices like pair programming, test-driven development (TDD), continuous integration, and frequent small releases
- A programming competition format where developers race to complete software features
- A Microsoft programming framework for developing extreme-scale enterprise applications
Answer : B Explanation: Extreme Programming (XP), created by Kent Beck in the late 1990s, is an Agile methodology focused on technical practices. Core XP practices: Pair Programming (two developers work together at one computer), Test-Driven Development — TDD (write the test before the code), Continuous Integration (integrate code frequently, at least daily), Refactoring (improve code structure without changing behavior), Small Releases (deliver working software frequently), On-site Customer (real customer is available full-time), Collective Code Ownership (anyone can modify any code), Simple Design (do the simplest thing that works), and Coding Standards. XP pairs well with Scrum — Scrum provides the management framework while XP provides the technical practices.
82. What is the purpose of acceptance criteria in Agile project management?
- Criteria used by the project manager to accept or reject team members for the project
- Specific conditions that a user story or deliverable must satisfy to be accepted as complete by the Product Owner or customer — defining the boundaries of a story and enabling testers to know when it is done
- Minimum performance benchmarks that software must achieve before entering testing
- The criteria used to accept bids from software development vendors and contractors
Answer : B Explanation: Acceptance Criteria define “done” for a user story from the business perspective. They are written collaboratively by the Product Owner and development team, typically in Given/When/Then format (from Behavior-Driven Development): “Given [context], When [action], Then [expected outcome].” Example for “As a user, I want to log in”: Given I am on the login page, When I enter valid credentials and click Login, Then I should be taken to my dashboard. Good acceptance criteria are: unambiguous, testable, achievable in a single sprint, and agreed upon before development begins. They prevent misunderstandings, guide development, and form the basis for testing.
83. What is Technical Debt in software project management?
- The financial debt incurred by purchasing expensive software development tools and licenses
- The implied cost of rework caused by choosing a quick, easy solution now instead of a better approach that would take longer — shortcuts in design or code that accumulate and slow future development
- The debt owed to technical vendors and contractors for software development services
- The gap between a developer’s current technical skills and the skills required for the project
Answer : B Explanation: Technical Debt, coined by Ward Cunningham, is a metaphor for the accumulated consequences of poor technical decisions made to ship faster. Like financial debt, it accrues “interest” — making future work slower and harder. Causes: quick-fix patches, skipping code reviews, inadequate testing, poor documentation, and outdated dependencies. Impact: slower feature development, more bugs, harder onboarding, and increased maintenance costs. Management: regular refactoring, code reviews, automated testing, clean code practices, and dedicating sprint capacity to debt reduction. Agile teams often track technical debt in the backlog. The key is making conscious trade-offs — sometimes taking on debt is acceptable if it is planned to be repaid.
84. What is the purpose of the Sprint Review in Scrum?
- A private team meeting where the Scrum Master reviews individual developer performance
- An end-of-sprint event where the development team demonstrates the completed increment to stakeholders, collects feedback, and updates the product backlog based on what was learned
- A management review meeting where executives decide whether to continue the project
- A code review meeting where developers review each other’s code for quality issues
Answer : B Explanation: The Sprint Review (not Sprint Retrospective — a common confusion) is an informal working meeting at the end of each sprint. The development team demonstrates the “Done” increment, stakeholders provide feedback, and the Product Owner updates the backlog based on this feedback and changing business priorities. Time-boxed to 4 hours for a 4-week sprint. Key outcomes: stakeholders see real working software (not just reports or presentations), feedback is gathered while changes are still relatively cheap, and the backlog is updated to reflect new understanding. The Sprint Review embodies the Agile principle of “responding to change over following a plan.”
85. What is the difference between a project baseline and a project plan?
- A baseline is an estimate; a project plan is the final approved version of the estimate
- A baseline is a fixed, approved snapshot of the project plan (scope, schedule, and cost) at a specific point in time, used as a reference to measure and track performance — changes require formal approval
- A project plan changes daily; a baseline is created only at project completion
- Both terms refer to the same document with different names used in different industries
Answer : B Explanation: The Project Baseline is the approved version of the project plan, formally agreed upon by stakeholders, that serves as the reference point for measuring performance and managing change. Three key baselines: Scope Baseline (approved project scope statement, WBS, and WBS dictionary), Schedule Baseline (approved project schedule with planned start and finish dates), and Cost Baseline (approved budget phased over time — the S-curve). Any change to a baseline requires formal change control approval. Earned Value Management (EVM) compares actual performance against these baselines to calculate variances. Without baselines, you cannot objectively measure whether the project is on track.
86. What is the Incremental development model in software engineering?
- A model where the entire software system is built and tested incrementally over many years
- A software development approach where the system is built and delivered in small, functional increments — each adding new capabilities while building on previous releases
- A model where only the incremental (new) features are tested in each development cycle
- A financial model that tracks incremental costs added to a software project over time
Answer : B Explanation: The Incremental Model builds the software in portions (increments) where each increment adds new functionality. The first increment is often the core product, and subsequent increments add features. Advantages: working software is delivered early (after first increment), reduces risk by getting user feedback sooner, easier to test smaller increments, accommodates changing requirements better than Waterfall, and allows parallel development of increments. Difference from iterative development: Incremental focuses on adding new functionality each cycle; Iterative refines the entire system through repeated cycles. Agile is both iterative and incremental. The Incremental model works well when requirements are prioritized and a partial system can be useful.
87. What is the purpose of the RACI matrix in project management?
- A financial matrix that tracks Revenue, Assets, Costs, and Investments in a project
- A responsibility assignment matrix that defines Responsible, Accountable, Consulted, and Informed roles for each project task or deliverable, clarifying who does what and preventing confusion
- A risk assessment matrix that rates risks by their Recurrence, Acuteness, Complexity, and Impact
- A project metrics framework tracking Requirements, Acceptance, Completion, and Integration
Answer : B Explanation: The RACI Matrix (also called Responsibility Assignment Matrix) is a tool for clarifying roles and responsibilities. RACI stands for: Responsible (who does the work — can be multiple people), Accountable (who is ultimately answerable — must be exactly ONE person per task), Consulted (who provides input and expertise — two-way communication), and Informed (who needs to be kept updated — one-way communication). RACI prevents common project problems: tasks with no owner, multiple people thinking they are accountable for the same thing, and key stakeholders not being consulted when they should be. The matrix rows list activities/deliverables; columns list team members/roles.
88. What is Definition of Done (DoD) in Agile/Scrum?
- The date when the entire project is scheduled to be completed and delivered to the customer
- A shared understanding among the Scrum team of the quality standards and completion criteria that every increment must meet before it can be considered “Done” and potentially releasable
- A document listing the individual acceptance criteria for each user story in the backlog
- The contractual definition of project completion agreed upon with the customer
Answer : B Explanation: The Definition of Done (DoD) is a shared checklist that defines what “complete” means for any increment of work. Unlike Acceptance Criteria (which are story-specific), the DoD applies to ALL stories. A typical DoD might include: code complete, unit tests written and passing, code reviewed by peer, integrated into main branch, automated regression tests pass, documentation updated, product owner has approved, and performance meets benchmarks. The DoD ensures quality consistency, prevents accumulation of “almost done” work, makes progress transparent, and gives the team and stakeholders confidence that increments are truly releasable. Teams should continuously refine their DoD to raise quality standards over time.
89. What is Monte Carlo simulation in project management?
- A card game-based team building exercise used in Agile project retrospectives
- A quantitative risk analysis technique that runs thousands of simulations using probability distributions for uncertain inputs to produce a probability distribution of possible project outcomes
- A project estimation technique where team members independently estimate tasks in isolation
- A scheduling technique for managing projects in multiple time zones simultaneously
Answer : B Explanation: Monte Carlo Simulation is a powerful quantitative risk analysis technique. Instead of using single-point estimates, it assigns probability distributions (triangular, normal, beta) to uncertain variables (task durations, costs). The simulation runs thousands of iterations, randomly sampling from these distributions each time, producing a range of possible outcomes with associated probabilities. Output: “There is a 90% probability of completing the project by June 30th and within $2.5M budget.” This is far more informative than a single deterministic estimate. Monte Carlo simulation helps project managers communicate schedule and cost uncertainty realistically and make informed decisions about contingency reserves.
90. What is the Agile Release Planning in Scrum?
- A single upfront planning session that defines all sprints for the entire project duration
- A planning activity that looks beyond a single sprint to map out a release roadmap — identifying which features will be delivered in which sprints to meet a release goal, based on team velocity and backlog priorities
- The final sprint planning meeting before a software version is released to customers
- A budget planning exercise that determines how much each software release will cost
Answer : B Explanation: Agile Release Planning (also called Release Planning or Big-Room Planning in SAFe) creates a high-level plan for a release that spans multiple sprints. The team reviews the prioritized Product Backlog, estimates how many backlog items they can complete per sprint based on velocity, and forecasts which sprint will deliver enough value for a release. Output: a release roadmap showing which features are planned for which sprints. This is a “rolling wave” plan — near-term sprints have detailed plans while future sprints have estimates. Release plans are regularly updated as velocity becomes more predictable and priorities change. Tools: Jira roadmaps, Azure DevOps boards, Rally.
