Agile Project Management Exam Questions and Answers (UNISA MNG 0001 / MNG 4351 / APM & Scrum Study Guide for South Africa)

Agile Project Management questions in South Africa’s university exams and professional assessments typically test not only Agile terminology (Scrum, Kanban, Epics, User Stories), but also the practical decision-making behind planning, estimation, prioritisation, and continuous improvement. This study guide provides exam-style questions with model answers across common Agile and Scrum knowledge areas that align with modules often referenced by South African learners in courses such as UNISA MNG 0001 (Project Management fundamentals) and related project management pathways, including strategy execution and delivery planning. It also includes scenarios, calculations (where relevant), and “best answer” reasoning—so you can pick the correct option under exam pressure.

1) Agile Fundamentals & Core Concepts (UNISA-style exam focus for Project Management fundamentals)

Agile Project Management is usually examined as a shift from traditional plan-driven delivery to iterative, incremental value delivery with transparency and adaptation. In South African universities, Agile content often appears in project management foundations modules (commonly framed similarly to MNG 0001-type content) and in advanced modules that relate to delivery, governance, and stakeholder alignment.

Typical Exam Question: Define Agile and explain why it was adopted

Question 1.1 (Short answer):
Explain what Agile Project Management is and provide two reasons it became popular in software and product development.

Model Answer:
Agile Project Management is an approach to managing projects that focuses on delivering value in small increments, using iterative planning, continuous feedback, and adaptation to change requirements.
Two reasons it became popular are:

Uncertainty and changing requirements: Agile accepts that early understanding is incomplete; it plans in cycles and can adjust.
Faster value delivery: Frequent releases reduce time-to-benefit and allow stakeholders to see progress early, reducing the risk of building the wrong solution.

Exam Tip: Marking often rewards explaining principle + outcome. Don’t only list a definition—attach a concrete “why” (e.g., earlier customer feedback reduces rework).

Typical Exam Question: Compare Agile with Waterfall

Question 1.2 (Multiple choice / structured response):
Which statement best contrasts Agile Project Management with Waterfall Project Management?

A. Waterfall delivers value incrementally every two weeks.
B. Agile requires a fixed scope agreed at project start, with minimal changes allowed.
C. Waterfall typically plans heavily up front, while Agile uses iterative delivery and adapts to change.
D. Agile eliminates stakeholders from the project.

Model Answer:
C. Waterfall typically uses sequential phases and heavy upfront planning, while Agile uses iterations, frequent stakeholder feedback, and adaptation as learning occurs.

Agile Values and Principles (What examiners often test)

You may be asked about the Agile Manifesto values or implied principles behind common practices. Exams usually reward you for linking values to behaviors.

Question 1.3 (Short answer):
List the four Agile Manifesto values and explain one practical implication of each.

Model Answer:
The four values are:

Individuals and interactions over processes and tools
- Practical implication: effective teamwork and communication reduce delays and rework.
Working software/product over comprehensive documentation
- Practical implication: prioritize delivering usable outcomes early rather than only producing extensive documents.
Customer collaboration over contract negotiation
- Practical implication: involve customers/product owners continuously to clarify priorities.
Responding to change over following a plan
- Practical implication: reprioritise backlog when new information appears rather than forcing the original plan.

Exam Tip: If you can only write limited time, do “value → behavior → benefit” for each value.

The Scrum Framework (Why it appears frequently)

Scrum is the most commonly examined Agile framework in university and certification contexts. The exam will likely ask you to describe roles, events, and artifacts, and—importantly—what each exists to achieve.

Roles: Product Owner, Scrum Master, Developers

Question 1.4:
Describe the responsibilities of the three Scrum roles.

Model Answer:

Product Owner (PO): Owns the product vision and manages the product backlog, ensuring priorities reflect stakeholder needs and value. The PO accepts that “what” gets built is decided and re-decided based on value and feedback.
Scrum Master: Facilitates Scrum implementation, helps remove impediments, coaches the team, and ensures Scrum events and rules are followed. The Scrum Master protects the process and improves the team’s effectiveness.
Developers: The cross-functional team that builds and delivers increments. They self-organise, plan how to meet Sprint goals, and deliver potentially shippable product increments.

Events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective

Question 1.5 (Structured response):
Explain the purpose of each Scrum event and what outcome is expected.

Model Answer:

Sprint (timebox): Provides a stable iteration period where a Sprint Goal can be achieved.
Sprint Planning: The team and PO decide what will be delivered and how. Outcome: Sprint Goal and selected backlog items with a plan.
Daily Scrum: Short coordination to inspect progress toward the Sprint Goal and adapt the plan. Outcome: updated plan for the next 24 hours.
Sprint Review: Inspect the increment with stakeholders and gather feedback for future backlog refinement. Outcome: feedback and adjustments to product backlog.
Sprint Retrospective: Inspect how the team worked and improve process/behaviors. Outcome: actionable improvement items.

Counter-Exam Trap: Many learners confuse Review (inspect product with stakeholders) with Retro (improve team/process). Ensure you clearly separate these.

Artifacts and transparency

Scrum artifacts are frequently examined because they create transparency and provide “evidence” that Scrum is working.

Product Backlog, Sprint Backlog, Increment

Question 1.6 (Short answer):
What are Scrum artifacts and why do they matter?

Model Answer:
Scrum artifacts are structured information models:

Product Backlog: prioritized list of what might be needed.
Sprint Backlog: subset selected for a Sprint plus a plan.
Increment: sum of product backlog items completed during the Sprint.
They matter because they enable transparency, inspection, and adaptation—key Agile properties.

Small Scenario: Choose the best Agile practice

Question 1.7 (Scenario):
A team has a backlog item described vaguely (“Improve dashboard”). The Product Owner wants it refined, but developers say it is “good enough” to start. What should happen next in Scrum?

Model Answer:
The Product Owner and Developers should ensure the backlog is refined so that the item is clear enough for planning. In Scrum terms, they should conduct backlog refinement: clarify acceptance criteria, define “ready” level, split into smaller items if needed, and ensure it can be completed during a Sprint.

Typical Calculation: Velocity and forecasting (carefully)

Agile exams sometimes test basic estimation logic. If numerical work appears, it is usually simple and not overly detailed.

Velocity basics (what it means)

Question 1.8 (Quantitative concept):
A team’s historical velocities for the last three Sprints were 8, 10, and 12 story points. What is their average velocity, and how would this be used for forecasting?

Model Answer:
Average velocity = (8 + 10 + 12) / 3 = 30 / 3 = 10 story points.
This average can inform how many story points the team might complete in a future Sprint, but forecasting is probabilistic—not a guarantee—because velocity can change with scope complexity, team changes, and learning.

Exam Tip: If asked “how,” mention probabilistic nature and that it supports selecting backlog capacity rather than committing to fixed outcomes.

2) Requirements, Backlog Management & Estimation Techniques (UNISA project delivery, prioritisation, and readiness)

This section focuses on the exam areas that often determine grades: how requirements are represented, how work is prioritised, how teams define “ready”, and how they estimate using Agile approaches. Many South African university syllabi include this as part of delivery planning and project governance.

Product Backlog and User Stories (the language of Agile)

User story anatomy

Question 2.1:
Explain what a user story is. Provide a template and an example for an e-commerce system.

Model Answer:
A user story is a short description of a capability written from the perspective of a user or stakeholder, typically including acceptance criteria.
Template:

As a [user/role],
I want [goal/capability],
so that [benefit/reason].

Example:

As a returning customer,
I want to see my past orders,
so that I can reorder quickly.

Acceptance criteria example (optional but good for marks):

Orders list shows order date and order status.
Only orders belonging to the customer are visible.

Acceptance Criteria & Definition of Done

Many Agile exams reward precise definitions of “done,” because it links Scrum practices to quality.

Definition of Done (DoD)

Question 2.2 (Short answer):
What is the Definition of Done in Scrum, and why must it be shared?

Model Answer:
The Definition of Done is a shared set of quality criteria that a Product Backlog item must satisfy to be considered complete. It must be shared so that everyone—PO, developers, and Scrum Master—has a consistent understanding of what “done” means, reducing disputes and improving reliability of increments.

Backlog Refinement and “Ready”

Question 2.3 (Scenario):
During refinement, the PO realises a story lacks acceptance criteria and depends on an external system not yet integrated. What should the team do?

Model Answer:
They should refine the story to add acceptance criteria and identify dependencies. The story may be split into smaller items, or a spike/research task may be created to reduce uncertainty. If dependency constraints mean it cannot be delivered soon, its priority can be adjusted, and the team may plan a separate Sprint for integration readiness.

Prioritisation: how the PO decides what comes next

Exams often ask you to justify prioritisation choices.

Value vs urgency vs risk

Question 2.4 (Structured response):
Explain three factors commonly used in backlog prioritisation.

Model Answer:

Business value: Benefit to users, revenue impact, strategic alignment.
Risk and uncertainty: Items that reduce uncertainty early may be prioritised.
Urgency/dependency: Items that unblock other work or are time-sensitive.

Prioritisation methods (common exam options)

You may be asked to match a method to a use case.

MoSCoW

Question 2.5:
What does MoSCoW stand for and how does it support backlog prioritisation?

Model Answer:
MoSCoW stands for Must, Should, Could, and Won’t (this time). It helps categorise requirements by importance and helps stakeholders agree on what must be delivered versus what can wait.

Example: A campus portal project backlog

Consider a university campus portal product (generic example used for illustration in exams):

Must: login and authentication
Should: profile management
Could: study timetable visualisation
Won’t this time: advanced notifications beyond email

WSJF (Weighted Shortest Job First)

Question 2.6 (Conceptual):
Explain WSJF and provide a reason why it might be used.

Model Answer:
WSJF prioritises jobs by considering the ratio of cost of delay to job size (effort/duration). It is used when organisations want to optimise value delivered over time, especially when delay has measurable business impact.

Estimation approaches in Agile (what exams test)

Story points vs hours

Question 2.7:
What is the difference between estimating in story points and estimating in person-hours?

Model Answer:

Story points estimate relative effort and complexity based on historical team performance and experience; they reflect uncertainty and complexity more than time.
Person-hours attempt to estimate absolute time needed.
Agile usually prefers story points because they handle uncertainty better and reduce false precision.

Planning poker and consensus

Question 2.8:
Describe Planning Poker and why it supports Agile estimation.

Model Answer:
Planning Poker is an estimation technique where team members privately select cards representing story point values. They reveal simultaneously, discuss discrepancies, and re-estimate until consensus is reached. It supports estimation by encouraging shared understanding of stories and collective team learning.

Practical estimation scenario (include numbers)

Question 2.9 (Quantitative scenario):
A team uses a simple rule for converting story points to capacity based on historical performance: average velocity is 10 story points per Sprint (from Section 1’s example). In a Sprint of one month, the team plans to include work for one week of discovery and three weeks of build, then expects to deliver around 0.75 × velocity.
How many story points do they forecast for this Sprint?

Model Answer:
Forecast story points = 0.75 × 10 = 7.5 story points.
In practice, the team would likely round down to plan 7 story points to reduce the risk of overcommitment, unless their context supports rounding up.

Exam Tip: If a question gives a formula (0.75 × velocity), apply it directly and then explain risk-aware rounding.

Estimation pitfalls examiners look for (write as “avoid this”)

Question 2.10:
Name three common estimation pitfalls in Agile and explain one consequence of each.

Model Answer:

Using story points as time: leads to false precision and creates pressure that undermines learning.
Estimating without clarity: results in frequent scope changes and unreliable forecasts.
Anchoring early to an initial guess: reduces team discussion and consensus, causing misestimates.

3) Agile Planning, Execution & Governance: Commitments, Risk, and Metrics (how exam answers score)

This section shifts from “what” Agile is to “how it is managed and measured.” In university exams and certification questions, this often appears as execution planning, commitment framing, risk management, and metrics.

Commitments in Scrum: Sprint Goal vs backlog coverage

Question 3.1:
What is a Sprint Goal and how does it differ from a commitment to complete all selected backlog items?

Model Answer:
A Sprint Goal is an objective for the Sprint that guides the team on why the Sprint is valuable. It differs from a commitment to complete all selected items because the team may adjust the plan during the Sprint to keep the Sprint Goal achievable. The team is focused on meeting the goal, not rigidly delivering a fixed checklist if learning shows better ways.

Counter-Argument to address (common exam confusion):
Some learners think Sprint Goal replaces accountability. It does not: the team still aims to deliver a working increment, but it can re-negotiate the plan within the Sprint to protect the goal.

Managing scope change mid-Sprint

Question 3.2 (Scenario):
A stakeholder requests a major change mid-Sprint that would take significant time. What should the team consider?

Model Answer:
The team should consider impact on the Sprint Goal, remaining capacity, and quality. In Scrum, significant scope changes are typically discouraged mid-Sprint because Scrum timeboxes planning. If the change is truly necessary, the PO and team may renegotiate scope and potentially adjust what is delivered, but the Sprint Goal remains the anchor. If the change undermines the goal, it may be deferred to a later Sprint.

Risk management in Agile (exam-friendly framing)

Agile does not “remove risk”; it manages risk by delivering early, reducing uncertainty, and continuously reprioritising.

Risk types

Question 3.3:
List three risk categories relevant in Agile projects and explain how Agile mitigates each.

Model Answer:

Technical risk (uncertainty in technology): Mitigated via spikes, prototypes, and early incremental delivery.
Requirements risk (unclear user needs): Mitigated through frequent stakeholder feedback in Sprint Reviews and backlog refinement.
Delivery risk (misalignment, integration issues): Mitigated using continuous integration, clear Definition of Done, and transparency.

Agile Metrics: what to measure and what to avoid

Exams often test metrics literacy: throughput, lead time, cycle time, burndown, burnup, and quality measures.

Burndown vs burnup

Question 3.4:
Explain the difference between a Burndown chart and a Burnup chart in Scrum.

Model Answer:

Burndown chart: shows work remaining over time. If scope changes, the chart may look misleading unless updated.
Burnup chart: shows work completed over time and can also show scope changes separately. Burnup can make scope changes more visible.

Lead time and cycle time

Question 3.5 (Conceptual):
Define lead time and cycle time. Provide one why each matters.

Model Answer:

Cycle time: time to complete a work item once it starts (often within a specific workflow stage).
Lead time: time from request/creation to completion.
Why they matter: reducing cycle time can improve responsiveness; reducing lead time can improve stakeholder satisfaction and planning accuracy.

Quality management: DoD, testing, and “potentially shippable”

Question 3.6:
What does “potentially shippable” mean in Scrum?

Model Answer:
It means the increment meets the Definition of Done and is in a usable state that could be released if the PO decides. It does not guarantee a release will occur, but it ensures readiness and quality.

Governance in Agile (how to answer if asked about control)

Many students fear “Agile = no governance.” Examiners expect that governance exists—but is adapted: transparency, inspection, and adaptation replace heavy control gates.

Question 3.7 (Structured response):
Describe how governance is achieved in Agile without relying solely on upfront documentation and stage gates.

Model Answer:
Governance is achieved through:

Transparency: backlog, sprint outcomes, and metrics are visible.
Inspection: frequent events (review and retro) enable checking product and process health.
Feedback loops: stakeholders review increments regularly, ensuring alignment.
Decision-making through prioritisation: PO manages investment choices using backlog ordering and acceptance of trade-offs.

Example: Agile governance dilemma with a fixed compliance requirement

Question 3.8 (Scenario):
A team must meet a compliance standard requiring specific audit documentation. How can they align this with Agile principles?

Model Answer:
They should integrate compliance documentation into the Definition of Done and delivery workflow rather than treating it as a separate “end-stage” activity. They can produce documentation incrementally (e.g., documentation per feature), use templates to reduce overhead, and maintain traceability from user stories to test evidence. This keeps documentation aligned with “working product over comprehensive documentation” while still meeting required governance.

Planning horizons (timeframes examiners love)

Question 3.9:
Explain at least three planning horizons in Agile and what decisions happen at each.

Model Answer:
Common horizons include:

Release planning (longer term): high-level goals, themes/epics, and approximate timing.
Sprint planning (short term): detailed selection of backlog items and a Sprint Goal.
Daily/iterative planning: plan for the next 24 hours, manage impediments and adapt within the Sprint.

4) Kanban, Hybrid Approaches & Scaling Agile (including metrics and exam scenarios)

Scrum is not the only Agile approach. Universities and certification exams often include Kanban, flow-based thinking, and hybrid models. Scaling Agile also appears—especially when questions ask about coordination across teams.

Kanban basics: flow vs timeboxes

Question 4.1:
Explain how Kanban differs from Scrum at a high level.

Model Answer:
Scrum uses timeboxed Sprints and defined events (Sprint Planning, Daily Scrum, Review, Retro). Kanban focuses on continuous flow using a visual board, limiting work in progress (WIP), and managing throughput and cycle times. Kanban does not require Sprints by default.

Kanban WIP limits (the heart of the method)

Question 4.2 (Scenario + conceptual):
A Kanban board has these columns: Backlog → Ready → In Progress → Review → Done. The team sets WIP limit of 2 for In Progress. In one day, three items are started. What is the likely consequence and what should they do?

Model Answer:
Likely consequence: multitasking increases, items spend longer in progress, and lead/cycle time typically increases; quality can degrade.
What to do: stop starting new work when WIP limit is reached, bring additional work by finishing or moving items forward, and manage bottlenecks by improving flow and clarifying acceptance criteria.

Service classes and policies

Question 4.3:
Describe the purpose of service classes in Kanban.

Model Answer:
Service classes categorise work by urgency and expected delivery time, allowing policies for prioritisation and capacity allocation. This helps prevent “everything is urgent” and improves predictability.

Escalation and risk management in Kanban

Question 4.4 (Scenario):
A critical incident ticket arrives and must be handled immediately, but the board already has WIP limits reached. How can the team respond while keeping Kanban principles?

Model Answer:
They should apply a policy for handling expedited work: either interrupt lower-priority work (if policy permits) or pause starting new work until capacity is freed. Expedited service classes may allow different WIP limits for different work types. The key is to keep the process explicit, transparent, and aligned to policies—so stakeholders understand trade-offs.

Hybrid approaches: Scrum+Kanban (exam-friendly framing)

Question 4.5:
What is a Scrum-Kanban hybrid and why might teams use it?

Model Answer:
A Scrum-Kanban hybrid retains Scrum events/roles but uses Kanban principles like WIP limits and flow visualisation within or across Sprints. Teams use it to better manage variability, reduce bottlenecks, and improve responsiveness while still benefiting from Scrum’s planning cadence.

Scaling Agile: multi-team coordination (common exam case)

Large organisations need structures to coordinate multiple teams. Exams may mention frameworks like SAFe, LeSS, or Nexus; however, many university questions stay conceptual.

Scaling challenges

Question 4.6:
Name three scaling challenges for Agile teams and suggest an Agile-aligned response to each.

Model Answer:

Coordination overhead: multiple teams working on interdependent components.
- Response: shared planning cycles, interface contracts, and integration checkpoints.
Inconsistent priorities and goals: teams optimise locally rather than globally.
- Response: align through product vision, portfolio-level prioritisation, and shared value themes.
Integration risk: frequent integration might still fail if dependencies aren’t managed.
- Response: define integration strategy, use incremental integration, and manage technical risk early.

Dependency management (exam scenarios)

Question 4.7 (Scenario):
Two Scrum teams share a dependency: Team A must deliver an API before Team B can complete stories. Team B’s Sprint depends on Team A’s Sprint timing. How should Team B respond?

Model Answer:
Team B should collaborate with Team A through explicit dependency management:

Include dependency work visibility (e.g., spikes, API stories) and establish a shared timeline plan.
Ensure Team A’s delivery meets acceptance criteria for Team B’s planned stories.
Use backlog refinement to split stories so Team B can deliver partially regardless of dependency (if possible).
If a dependency slips, adjust scope while protecting Team B’s Sprint Goal and communicate trade-offs through the PO.

Metrics when scaling

Question 4.8:
In scaled Agile, why might measuring individual team velocity be insufficient?

Model Answer:
Because value delivery depends on end-to-end flow across teams. Individual velocities can look healthy while integration delays or cross-team bottlenecks slow overall lead time. Scaled metrics often include system-level flow metrics like end-to-end lead time, throughput, and predictability of releases.

5) Agile Exam Questions Bank: Scenario-Based Answers, Common Mistakes, and Quick Decision Rules (UNISA-compatible exam practice)

This final section is designed as a high-yield exam questions bank. It includes frequently tested styles: define/compare, scenario selection, “choose the best next step,” and short quantitative logic. It also provides quick rules and common mistakes so you can write better answers faster under time pressure.

A) Knowledge & Definitions (write these clearly)

Question 5.1 (Definition): Scrum vs Kanban

Question:
Explain one key difference between Scrum and Kanban and one similarity.

Model Answer:
Difference: Scrum uses timeboxed Sprints and defined Scrum events; Kanban uses continuous flow and emphasizes WIP limits.
Similarity: both aim for iterative delivery with transparency and continuous improvement.

Question 5.2 (Definition): Epics, Stories, Tasks

Question:
Differentiate between an Epic, a User Story, and a Task.

Model Answer:

Epic: a large body of work that can span multiple Sprints and is often broken down into multiple stories.
User Story: a smaller deliverable that describes a user value and is typically manageable within fewer stories.
Task: a concrete activity required to implement a story; tasks support sprint execution planning.

B) Scenario Questions (choose the best answer and justify)

Question 5.3 (Sprint Planning scenario)

Scenario:
A team’s Sprint Planning ends with a plan to start many items immediately, but the Sprint Goal is missing. The PO says: “We will just deliver whatever we can.”
What is the best improvement?

Model Answer:
The best improvement is to establish a clear Sprint Goal during Sprint Planning and select work that supports it. Without a Sprint Goal, the team lacks a guiding objective and may deliver disconnected items. Sprint Planning should produce both: (1) selected backlog items and (2) a Sprint Goal that clarifies the intent and value of the Sprint.

Question 5.4 (Daily Scrum misuse)

Scenario:
The Daily Scrum becomes a problem-solving meeting where developers debate long technical solutions. It lasts 45 minutes.
What should the team do?

Model Answer:
Daily Scrum should be short—typically 15 minutes—and focus on inspecting progress toward the Sprint Goal and adapting for the next 24 hours. Technical deep dives should be moved to after the Daily Scrum (or into dedicated working sessions). The Daily Scrum should answer:

What did I complete that helps the Sprint Goal?
What will I do next?
What impediments block me?

Question 5.5 (Sprint Review confusion)

Scenario:
A team uses the Sprint Review to discuss internal process problems and writes improvement actions.
Where is this happening incorrectly?

Model Answer:
This is incorrect because process improvements and internal ways of working belong in the Sprint Retrospective. The Sprint Review should focus on inspecting the product increment with stakeholders and gathering feedback. The retrospective is the event intended to define improvement actions.

Question 5.6 (Retro quality)

Scenario:
In the Sprint Retrospective, the team blames individuals and discusses who is at fault. No improvement items are agreed.
What is the best next action?

Model Answer:
The team should shift from blame to improvement by focusing on systems and behaviors. They should identify actionable improvement items, including an owner and a measurable focus. The Scrum Master should facilitate so discussions lead to improvement decisions, not personal criticism.

C) Estimation & Planning practice questions

Question 5.7 (Relative estimation)

Question:
Why do Agile teams prefer relative estimation (e.g., story points) over exact time estimates?

Model Answer:
Relative estimation better reflects uncertainty and complexity without creating false precision. It supports planning decisions and forecast stability using team history (velocity) rather than pretending we can predict exact hours. This encourages learning and reduces the negative impacts of “schedule as commitment” thinking.

Question 5.8 (Acceptance criteria)

Scenario:
A user story is: “As a user, I want to reset my password.” The team finishes UI changes but stakeholders complain there’s no audit trail and no email confirmation.
What should have existed?

Model Answer:
The story should have included clear acceptance criteria and possibly dependency requirements such as audit trail logging and confirmation email behavior. In addition, the Definition of Done would ensure required quality aspects are completed.

D) Metrics and charts: interpret typical results

Question 5.9 (Burndown interpretation)

Scenario:
A burndown chart shows work remaining decreasing one week, then staying flat for two days, then dropping sharply.
What might be happening?

Model Answer:
It may indicate that work was not completed (or moved forward) for a period—perhaps due to impediments—followed by a burst of completion. Sharp drops can also happen if remaining work is re-estimated or if scope changes are not accurately reflected. The correct exam answer is to link pattern to likely causes and suggest follow-up using inspection.

Question 5.10 (Cycle time and WIP)

Question:
If WIP limits are increased, what generally happens to cycle time?

Model Answer:
Generally, increasing WIP limits increases multitasking and queueing, which typically increases cycle time. Exams expect the flow-based reasoning: more work in progress leads to longer time to completion.

E) Governance & compliance scenarios

Question 5.11 (Documentation vs agility)

Scenario:
An organisation requires detailed documentation before any release. The team wants to deliver quickly with Agile increments.
How can they reconcile this?

Model Answer:
They can treat documentation as part of the delivery process by integrating documentation requirements into the Definition of Done. For example, produce documentation incrementally as features complete, use templates, and ensure traceability from user stories and test evidence to compliance requirements. This respects the Agile value of “working product” while fulfilling compliance governance.

Question 5.12 (Stakeholder management)

Scenario:
Stakeholders attend Sprint Reviews but don’t provide feedback; the PO says: “They’re busy.”
What is the best next step?

Model Answer:
The PO should proactively structure stakeholder feedback: provide clear demo scripts, focus review on acceptance criteria and outcomes, and ask explicit questions tied to prioritisation. For example: “Does this meet the critical acceptance criteria?” and “Which backlog item should we prioritise next based on your feedback?” Also clarify that Sprint Review is a required feedback loop for adaptation.

F) Quick decision rules (“best next step” logic)

Exams often reward crisp decision rules. Use these as “writing frameworks”:

Question 5.13 (Framework): Which event fits which need?

Question:
Match the Agile event to the primary goal:

inspect product with stakeholders
improve team working practices
coordinate daily progress
plan sprint scope and goal

Model Answer:

Inspect product with stakeholders → Sprint Review
Improve team working practices → Sprint Retrospective
Coordinate daily progress → Daily Scrum
Plan sprint scope and goal → Sprint Planning

Question 5.14 (Framework): What to do when requirements change?

Question:
A new requirement becomes valuable during a Sprint. What should happen?

Model Answer:
In Scrum, evaluate impact on Sprint Goal and increment. Significant scope changes are usually avoided during a Sprint timebox; instead, the PO may adjust the backlog for future Sprints. If the change is critical and small enough to fit without breaking the Sprint Goal, the plan can be adapted; otherwise, defer it and communicate the trade-off.

G) Mini-papers / long-form exam prompts with model answers

These prompts resemble assignments or longer exam questions where you must explain reasoning.

Question 5.15 (Long-form): Agile vs Waterfall in project risk management

Prompt:
“Discuss how Agile Project Management manages project risk compared with Waterfall. Include examples of two risks and mitigation practices.”

Model Answer (exam-quality):
Agile manages risk by reducing uncertainty through iterative delivery and continuous stakeholder feedback. In Waterfall, risks are often addressed with upfront planning and stage gates; however, when requirements change or understanding improves late, rework becomes expensive and schedule slippage occurs.

Two key risks are:

Requirements risk: In Waterfall, if requirements are misunderstood early, the project may build the wrong solution. Agile mitigates this by delivering increments and using Sprint Reviews to obtain frequent feedback. Backlog refinement clarifies acceptance criteria, enabling better alignment over time.
Technical risk: In Waterfall, technical unknowns often surface late because integration and validation happen toward the end. Agile mitigates technical uncertainty through early prototypes, spikes, and continuous integration practices, allowing the team to learn sooner and adjust architecture or approach.

Additionally, Agile reduces delivery risk by using transparency (visible backlog and progress), inspection (events), and adaptation (reprioritisation and sprint plan adjustments). While Agile does not eliminate risk, it shortens feedback cycles, making issues visible earlier—thereby lowering the cost of change and increasing the chance of delivering value.

Question 5.16 (Long-form): Backlog management and estimation justification

Prompt:
“Explain how backlog refinement and estimation techniques improve planning accuracy in Scrum. Include at least one estimation technique and how it supports decision-making.”

Model Answer:
Backlog refinement improves planning accuracy by ensuring that future work is sufficiently understood before it enters a Sprint. Without refinement, stories may lack clarity, acceptance criteria, or awareness of dependencies. As refinement progresses, items are decomposed, clarified, and prepared to meet the team’s “ready” definition—reducing the likelihood of mid-sprint surprises.

Estimation techniques such as Planning Poker support decision-making by enabling the team to reach a shared understanding of relative complexity and effort. Story points estimate relative size, complexity, and uncertainty rather than precise time. Teams use historical velocity (e.g., average story points completed per Sprint) to forecast likely capacity, enabling the PO to balance value and risk by selecting an appropriate amount of work.

Together, refinement and estimation produce more reliable Sprint plans and better stakeholder confidence. They also support adaptive planning: if refinement reveals higher complexity than expected, the team can adjust backlog ordering and future commitments rather than failing later under inaccurate assumptions.

H) Full-length “practice exam” (timed-style set)

The questions below are designed to simulate the flow of an exam. If you answer them in sequence, you will build speed and correctness.

Practice Exam Set

Define Agile Project Management and list two Agile Manifesto values.
Explain the purpose of Sprint Review and Sprint Retrospective; differentiate between them.
In Scrum, who is responsible for managing the product backlog, and what does “ownership” practically mean?
Provide one example of good user story writing using the “As a / I want / so that” format. Add at least two acceptance criteria.
Describe two backlog prioritisation factors and justify which factor you would prioritise when a high-risk dependency exists.
Explain velocity and how it should be used for forecasting.
Provide one reason why WIP limits matter in Kanban.
A team’s burndown chart stays flat for several days. Name two possible causes and explain how the team should inspect and adapt.
Explain one governance mechanism in Agile that does not rely solely on stage-gate documentation.
Write a short “best next step” response: a major change request arrives mid-sprint—what does the PO do and how does the team protect the Sprint Goal?

Model Answer Guide (high-level):

Use Scrum events definitions correctly; separate Review vs Retro.
Clarify PO vs Scrum Master vs Developers roles.
User stories should include acceptance criteria.
Prioritisation should tie to value/risk/dependencies.
Velocity is average capacity and forecasts probabilistically.
Kanban WIP limits reduce multitasking and improve cycle time.
Burndown patterns require inspection (impediments, dependency delays, scope changes).
Governance via transparency, inspection, adaptation, and Definition of Done compliance.

Additional South Africa Learning Alignment (course-style language commonly used in UNISA and similar modules)

How to write answers that score marks in South African university assessments

Many learners lose marks not because they “don’t know Agile,” but because their exam responses are too vague. High-scoring responses typically follow a pattern:

Correct terminology (Scrum roles/events/artifacts; DoD; backlog; refinement; velocity; WIP).
Purpose statement (why the practice exists).
Concrete outcome (what you get at the end of the event/practice).
One example (scenario reasoning or mini-case).
Avoid common confusion (Review vs Retro; tasks vs stories; time estimates vs story points).

If a question says “discuss,” you usually need more than definitions—you need comparison, reasoning, and at least one example.

Common mark-losing mistakes (and how to avoid them)

Mistake 1: Treating Daily Scrum as status reporting to a manager.

Fix: It is coordination around the Sprint Goal: progress and impediments; talk to the plan, not the org chart.

Mistake 2: Saying Sprint Goal is optional.

Fix: Sprint Goal provides focus. If missing, you lose coherence and purpose.

Mistake 3: Confusing backlog refinement with Sprint Planning.

Fix: Refinement prepares future work; Sprint Planning selects work and creates the Sprint plan for the Sprint.

Mistake 4: Saying “Agile has no documentation.”

Fix: Agile prefers purposeful documentation produced incrementally, aligned to Definition of Done and compliance needs.

Mistake 5: Using story points as hours.

Fix: Story points are relative estimates; hours may be used for operational staffing but not as the Agile estimation anchor.

Final checklist for exam answers (quick template)

Before submitting a response, check that your answer includes:

One correct definition or distinction
At least one “why it matters”
Correct mapping to the Agile mechanism (which event/role/artifact)
A brief example or scenario application when asked “discuss” or “scenario”
Clear separation when the question contrasts concepts (e.g., Scrum vs Kanban; Review vs Retro)

Summary of Exam-Ready Agile Concepts Covered

This study guide has covered:

Agile values and principles and their practical meaning
Scrum roles, events, and artifacts and why they exist
Product backlog management, user story structure, acceptance criteria, and Definition of Done
Estimation basics including story points, Planning Poker, velocity, and forecasting logic
Agile planning and execution: Sprint Goal, daily adaptation, risk management, and quality readiness
Kanban flow principles: WIP limits, service classes, and continuous improvement
Scaling Agile concepts: dependencies, system-level metrics, and end-to-end flow thinking
A comprehensive bank of exam-style questions and model answers, including long-form prompt solutions

If you want, share the exact module code(s) you’re using (e.g., MNG 0001 or any other UNISA paper code, plus your exam format: multiple choice vs essays), and I can generate a fully aligned set of practice papers with mark allocations and a correction rubric.