Agile is more than a set of ceremonies—it is an approach to values and decision-making under uncertainty. The Agile Manifesto provides the underlying philosophy (values and principles), while Agile practices (e.g., Scrum, Kanban, and engineering practices) translate that philosophy into day-to-day delivery. These exam notes focus on what you must know for common South African university assessments, including UNISA project management and Agile/Scrum-related modules, and they summarize both principles and practical implementation.
UNISA & Project Management Agile Focus: Understanding the Agile Manifesto Values and Principles (for MNG 0001 / PMSA / PM-related modules)
South African students in the UNISA and similar environments often encounter Agile through project management curricula: managing scope, time, cost, risk, quality, and stakeholder communication using iterative approaches. The Agile Manifesto is the “why,” and Agile practices are the “how.”
The Agile Manifesto: The Four Values (What to Remember for Exams)
The Agile Manifesto (2001) states that individuals and teams build better software and solutions when they value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
For exam questions, you should be able to interpret each value, explain typical trade-offs, and show how it changes project behaviour.
1) Individuals & Interactions > Processes & Tools
This value does not mean “process is bad.” It means processes and tools should serve people, not replace them. In project terms:
- When decisions are blocked by procedure alone, agility fails.
- When teams communicate early and openly, the project adapts faster.
Example (UNISA-style scenario):
A delivery team must follow a strict change-control workflow. Under strict process-only thinking, a change request takes 3 weeks to be approved. Under agile thinking, the team uses a lightweight review and decides whether a change belongs in the next sprint/backlog cycle. The process exists, but it doesn’t dominate outcomes.
Exam language to use:
- “Process is supportive; collaboration is primary.”
- “Quality decisions come from people, not documents.”
2) Working Software > Comprehensive Documentation
Agile prefers documentation that helps deliver value. However, “working software” doesn’t remove documentation—it changes its timing and type:
- Documentation is just enough and just in time.
- Over-documenting can delay feedback loops.
Common confusion for students:
“Working software” is sometimes misinterpreted as “no documentation.” A better exam answer:
- Agile reduces waste in documentation and emphasizes documentation that enables learning and trust (e.g., user stories, acceptance criteria, definition of done).
Example:
Instead of producing a full requirements specification up front, the team writes:
- User stories with acceptance criteria,
- Updated models where needed,
- Test cases and release notes as part of “done.”
3) Customer Collaboration > Contract Negotiation
This value focuses on the project’s human relationship:
- Contracts are still important, but they shouldn’t freeze the relationship.
- Collaboration reduces misunderstandings and rework.
Exam-ready nuance:
Agile doesn’t ignore legal/financial obligations. It shifts the emphasis:
- From “win/lose contract terms,”
- To “co-create outcomes with the customer.”
Example:
A university partnership project uses a fixed budget. That is not the same as a fixed scope. The parties collaborate on priorities, and the budget constrains choices while agility determines sequencing.
4) Responding to Change > Following a Plan
This is the most “principle-like” value. Traditional plans assume stability; agile assumes uncertainty:
- Teams plan in iterations.
- They gather evidence quickly and adjust.
Key exam phrasing:
- “Plans are hypotheses, not promises.”
- “Change is treated as information.”
The 12 Agile Principles: What They Mean in Practice
The Agile Manifesto’s 12 principles describe how to make the four values real. For exams, you must not only list them, but connect each to project outcomes such as risk reduction, customer satisfaction, and sustainable delivery.
Below are the principles with exam-friendly explanations and practical signals.
Principle 1: Customer satisfaction through early and continuous delivery
Meaning: Deliver value early, then keep improving frequently.
Practice signals: short feedback cycles, incremental releases, demos at regular intervals.
Principle 2: Welcome changing requirements, even late in development
Meaning: Treat late changes as learning opportunities.
Practice signals: backlog refinement, re-prioritization, ability to swap what’s in the sprint (within rules).
Principle 3: Deliver working software frequently
Meaning: Frequent delivery reduces uncertainty and provides tangible progress.
Practice signals: timeboxed sprints (e.g., 2 weeks), continuous integration and testing.
Principle 4: Business people and developers must work together daily
Meaning: Collaboration eliminates handoff delays.
Practice signals: product owner availability, daily interaction, shared understanding of “done.”
Principle 5: Build projects around motivated individuals; give them the environment and support they need
Meaning: Motivation and empowerment are operational assets.
Practice signals: decision-making authority, clear goals, psychological safety, reasonable workload.
Principle 6: The most efficient and effective method of conveying information is face-to-face conversation
Meaning: Communication richness matters; not every message should be written-only.
Practice signals: daily stand-ups, workshops, pairing, co-located sessions (or high-quality virtual equivalents).
Principle 7: Working software is the primary measure of progress
Meaning: Progress is measured by outcomes, not activity.
Practice signals: release metrics, acceptance tests, demo results, value delivered.
Principle 8: Agile processes promote sustainable development
Meaning: Teams must avoid burnout; pace matters.
Practice signals: limiting work in progress (WIP), capacity planning, avoiding “always urgent.”
Principle 9: Continuous attention to technical excellence and good design
Meaning: Architecture and engineering quality reduce rework.
Practice signals: refactoring, automated tests, code reviews, design principles.
Principle 10: Simplicity—the art of maximizing the amount of work not done
Meaning: Choose the simplest effective solution.
Practice signals: MVP thinking, incremental design, remove unnecessary features.
Principle 11: Best architectures, requirements, and designs emerge from self-organizing teams
Meaning: Teams discover solutions through collaboration and ownership.
Practice signals: team-led planning, collective ownership of tasks.
Principle 12: Regularly, the team reflects and adjusts behavior to become more effective
Meaning: Inspect-and-adapt is continuous.
Practice signals: sprint retrospectives, improvement backlogs, experiments.
Turning Manifesto Principles into Exam-Useful “Cause → Effect” Statements
In many South African project management exams, you earn marks when you connect principles to effects.
Here are cause→effect templates you can adapt:
- If teams deliver frequently, then customers give faster feedback → less rework and higher satisfaction.
- If change is welcomed, then requirement risk decreases → better product-market fit.
- If technical excellence is continuous, then defects reduce → more predictable delivery.
- If teams reflect regularly, then process maturity improves → better throughput over time.
Counter-Arguments and Misuses (How to Score High on “Critically Discuss” Questions)
Agile is sometimes criticized. Exams often expect balanced arguments. Common critiques include:
Critique 1: “Agile reduces documentation quality”
Counter-argument: Agile uses just enough, right-time documentation. Evidence: user stories and acceptance criteria, test cases, technical documentation evolving with learning.
High-mark answer angle:
- “The issue isn’t documentation; it’s wasteful documentation.”
Critique 2: “Agile causes scope creep”
Counter-argument: Agile manages change through prioritization, backlog ordering, and iteration planning. Scope creep becomes controlled re-prioritization.
High-mark answer angle:
- “Change is constrained by capacity and selection mechanisms.”
Critique 3: “Agile is chaotic”
Counter-argument: Agile has structure (timeboxes, roles, backlog, definition of done). Chaos appears when teams lack discipline in engineering and prioritization.
High-mark answer angle:
- “Agile provides guardrails; it doesn’t remove them.”
UNISA & Scrum/Predictable Delivery: Core Scrum Roles, Events, Artifacts, and How They Implement Agile (for CIL/CNS/ITPM-style PM modules)
Scrum is the most commonly taught Agile framework in South African universities. While Kanban and other approaches exist, Scrum provides a strong structure that examiners love because it is easy to define precisely.
Scrum’s Goal: Make Agile Principles Operational
The Scrum framework is built to deliver value iteratively and incrementally. Its purpose is to:
- Support frequent inspection and adaptation,
- Enable transparent prioritization and delivery,
- Create a rhythm for planning, execution, review, and improvement.
Scrum is not synonymous with Agile, but it is a widely used implementation of Agile values and principles.
Scrum Roles: Who Does What (and What Examiners Look For)
Scrum has three official roles:
- Product Owner (PO)
- Scrum Master (SM)
- Developers (the team members who build the product)
Product Owner responsibilities (exam essentials)
The Product Owner:
- Owns the Product Backlog
- Defines and communicates product priorities
- Ensures the team builds the right things
- Represents stakeholder needs and manages trade-offs
Key exam point: The PO is not a “project manager who assigns tasks.” In Scrum, the Developers decide how to build the work, while the PO decides what to build next.
Scrum Master responsibilities
The Scrum Master:
- Facilitates Scrum events
- Coaches the team on Scrum and Agile practices
- Removes impediments (or helps the team remove them)
- Ensures transparency and continuous improvement
Key exam point: The Scrum Master does not “control” the team. They serve the process and help remove blockers.
Developers responsibilities
Developers:
- Build increment(s) that meet Definition of Done
- Participate in planning and daily coordination
- Collaborate to refine the work and achieve sprint goals
Key exam point: “Developers” means the people who do the development work, not necessarily only programmers.
Scrum Events: Timeboxed Mechanisms for Inspection & Adaptation
Scrum has five main events:
- Sprint (timebox)
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
Sprint
A Sprint is a short, consistent timebox (commonly 1–4 weeks, with many teams using 2 weeks).
Exam essentials: The backlog can change between sprints, but within a sprint the sprint goal is protected.
Sprint Planning
During Sprint Planning, the team answers:
- What increment can we deliver by the end of the sprint?
- How will we build the selected items?
Practical breakdown:
- PO clarifies priority and value.
- Developers estimate and select work that fits capacity.
- Team forms a sprint goal (the “why” of the sprint).
Daily Scrum
The Daily Scrum answers:
- What did I do that helps the sprint goal?
- What will I do next?
- What impediments block progress?
Exam-friendly note: It’s not a status meeting for the manager. It’s a team coordination tool.
Sprint Review
The team demonstrates what was delivered and gathers feedback from stakeholders.
Exam essentials: The review is not a retrospective; it’s about acceptance of outcomes and learning.
Sprint Retrospective
The team reflects on how to become more effective and defines improvements for the next sprint.
Exam essentials: Improvements must be specific and actionable; otherwise retrospectives become “complaint meetings.”
Scrum Artifacts: Transparency Tools
Scrum artifacts ensure transparency:
- Product Backlog
- Sprint Backlog
- Increment
Product Backlog
An ordered list of everything that might be needed.
The PO maintains ordering; Developers contribute estimates and clarity.
Sprint Backlog
The subset of backlog items chosen for the sprint plus the plan for delivering them.
Developers update it as the plan evolves toward sprint goal.
Increment
The sum of all completed Product Backlog items during a sprint and previous sprints’ increments, meeting Definition of Done.
Definition of Done: The Quality Gate Examiners Love
A Definition of Done (DoD) clarifies what “done” means. It typically includes:
- Code completed
- Code reviewed
- Automated tests passing
- Documentation updates (minimal but adequate)
- Security checks (if relevant)
- Deployment readiness
Why it matters:
Without a DoD, “progress” becomes misleading. Principle 7 says working software is primary measure of progress; DoD makes that measurable.
Example Case Study: Scrum in a University IT Systems Development Context
Consider a fictional UNISA internal project to develop an online student services portal. The objective is to reduce manual requests by enabling:
- Password reset,
- Viewing application status,
- Uploading supporting documents.
Sprint 1:
- Goal: Enable status viewing with basic authentication.
- Selected backlog includes user stories and UI forms.
- Acceptance criteria define what “works” means (e.g., students see correct status categories).
Sprint 2:
- Goal: Add document upload with validation rules.
- Developers implement file upload and error handling; PO adjusts priorities based on stakeholder feedback from Sprint Review.
Sprint 3:
- Goal: Add self-service password reset.
- Team uses improvements from Sprint Retrospective (e.g., improved test coverage and clearer data validation).
Exam angle:
- How Scrum supports Agile principle 1 (early and continuous delivery).
- How feedback at Sprint Review changes priorities (principle 2).
- How technical excellence and testing prevent defects (principle 9).
Common Exam Questions and Model Answers (Short Templates)
Q: “Explain the role of the Scrum Master.”
Model answer elements:
- Servant-leader to the team and organization
- Facilitates events
- Removes impediments
- Coaches on Agile/Scrum practices
- Protects transparency and continuous improvement
Q: “How does Scrum support responding to change?”
Model answer elements:
- Change is handled via Product Backlog reordering
- Sprint goals protect delivery while still allowing learning
- Sprint Reviews validate assumptions with stakeholders
- Retrospectives drive process improvements
UCT / Wits / Higher-Education Agile Patterns: Kanban, Flow, and Lean Delivery Practices (plus why they differ from Scrum)
While Scrum is timeboxed, many Agile implementations in real organizations—especially service and operations environments—use Kanban. South African universities often include “compare/contrast” questions, and it is valuable to distinguish the mental model: timeboxing (Scrum) versus flow (Kanban).
Kanban Essentials: Visualizing Work and Managing Flow
Kanban focuses on:
- Visualizing work,
- Limiting work-in-progress (WIP),
- Managing and improving flow efficiency.
A typical Kanban board includes columns such as:
- Backlog
- Ready
- In Progress
- Code Review
- Testing
- Done
Exam-friendly concept:
WIP limits reduce multitasking and improve throughput.
Why flow matters (link to Agile principles)
Kanban can align with Agile values by:
- Encouraging rapid feedback loops,
- Reducing delays between starting and finishing work,
- Improving quality continuously.
Scrum vs Kanban: A Comparison You Can Use in Exams
Use this comparison framework:
| Aspect | Scrum | Kanban |
|---|---|---|
| Main planning unit | Sprint (timebox) | Continuous flow |
| Roles | PO, SM, Developers | Often lighter roles; may vary |
| Backlog handling | Product Backlog, sprint selection | Backlog replenishes as capacity frees |
| Measuring progress | Completed increments per sprint | Flow metrics (lead time, throughput) |
| Risk control | Iterative delivery and review | Continuous handling of variability |
Exam tip: Examiners like precise differences:
- Scrum “plans” into a sprint.
- Kanban “absorbs work continuously” with WIP control.
Lean Practices Common in Agile Environments
Lean thinking strongly influences Agile delivery. Key Lean practices include:
- Eliminate waste (unnecessary steps, waiting, over-processing)
- Build quality in (reduce rework)
- Optimize the whole system (not local efficiency)
- Respect people (sustainable pace and empowerment)
In project exams, “waste” often includes:
- Waiting for approvals,
- Rework due to unclear requirements,
- Large batches that delay feedback,
- Excessive handoffs.
Flow Metrics: What to Track and Why
In Kanban (and broader Agile), metrics support learning. Common metrics include:
- Lead time: from request/commitment to delivery
- Cycle time: from “in progress” to delivery
- Throughput: completed items per unit time
- WIP levels: number of items in progress
Example: Reducing lead time in a support team
Suppose a team handles change requests for a student portal. Over several weeks:
- Average cycle time is high because tickets wait in “testing.”
- By limiting WIP and improving test automation, testing becomes faster.
- Result: lead time decreases and predictability improves.
Exam angle:
Tie metrics to Agile principle 8 (sustainable development) and principle 10 (simplicity—avoid unnecessary work batches).
Counter-arguments: Is Kanban “Less Agile”?
Some argue that Kanban is not “Agile” because it lacks timeboxed sprints. A strong answer:
- Agile values and principles are broader than a specific framework.
- Kanban can implement inspection/adaptation via replenishment meetings and service delivery reviews.
- If WIP limits and flow improvements are actively used, the team still learns continuously.
Transitioning from Scrum to Kanban (A Realistic University/Department View)
Organizations often transition to Kanban when:
- Work arrives unpredictably (support, operations, incidents),
- Continuous delivery is beneficial,
- Sprint boundaries don’t fit demand patterns.
A pragmatic approach:
- Start with the same team and a shared board
- Introduce WIP limits by state
- Measure lead time and throughput
- Run regular replenishment/coordination meetings
- Improve policies based on results
Exam-ready statement:
The goal is not to “change labels” but to improve delivery effectiveness.
South African Exam Practice: Engineering Practices, Risk Management, and “What Counts as Agile” (quality, testing, stakeholder alignment)
Agile exams frequently assess whether you understand that Agile principles require engineering discipline. Without engineering practices, “Agile” becomes slides, meetings, and demos—rather than delivered quality.
Engineering Practices That Implement Agile Values
To deliver “working software” frequently and sustainably, teams need practices such as:
- Continuous integration (CI)
- Automated testing
- Refactoring and incremental design
- Code reviews and shared ownership
- Definition of Done and quality gates
- Release management and deployment automation
Continuous Integration (CI)
CI means code is integrated regularly (often daily) and validated automatically.
Why it matters:
- It shortens the feedback loop from “we changed something” to “we know whether it breaks.”
- It reduces integration risk.
Typical exam scenario:
A team postpones integration until the end of a sprint. Defects explode late. Under CI, defects appear quickly, allowing rework earlier.
Automated Testing
Agile prefers tests that are:
- Fast enough to run frequently,
- Reliable enough to support confident releases,
- Clear in what they verify.
Test layers often include:
- Unit tests
- Integration tests
- End-to-end tests
- Regression tests
Exam angle:
Automated tests are not “extra” documentation; they are execution evidence that supports principle 7 (progress measured by working product).
Refactoring
Refactoring improves design without changing external behaviour.
It supports:
- Technical excellence (principle 9),
- Simplicity (principle 10),
- Longer-term maintainability.
Exam pitfall:
Refactoring is sometimes wrongly seen as optional “cleanup.” A strong answer:
- Refactoring reduces future costs by preventing architectural debt.
Quality and “Working Software” in Non-Software Projects
Agile is often taught in software, but exams may ask you to generalize. “Working software” can mean:
- Working prototypes,
- Operational processes working end-to-end,
- Service outcomes verified (e.g., a student can complete a registration flow successfully).
In an academic context:
- A “done” feature could be a functioning enrollment workflow with correct validations, audit logs, and accessible UI.
Risk Management in Agile: Managing Uncertainty Iteratively
Risk in Agile is handled through:
- Frequent delivery,
- Early feedback,
- Continuous discovery,
- Iteration-based planning.
Instead of a big up-front risk plan that becomes outdated, Agile uses risk reduction cycles:
- Identify assumptions early,
- Validate them with prototypes,
- Adjust based on evidence.
Example: Reducing requirement risk for a mobile app
Assume a stakeholder claims students will strongly prefer mobile access. Agile approach:
- Build a minimal mobile login and status page,
- Test with a small group of students early,
- Measure usability outcomes (e.g., task success rate),
- Decide whether to invest further.
Exam-ready phrase:
“Agile turns high-uncertainty work into experiments.”
Stakeholder Collaboration and Communication Policies
Agile requires customer collaboration, but “collaboration” must be structured:
- Who provides feedback?
- How often?
- What response time is expected?
- How are decisions made?
Common stakeholder mechanisms:
- Sprint Reviews (formal feedback)
- Backlog refinement (clarify requirements)
- Demo days (optional but common)
- Working sessions (user story workshops)
Counter-argument: “Stakeholders can slow delivery”
Yes, if stakeholders are unavailable or unclear, agility fails. Balanced answer:
- Agile reduces dependency on perfect up-front specification, but it still needs timely feedback.
- Organizations can improve collaboration by setting response windows and decision rules.
Sustainable Development: Avoiding Burnout as a Project Failure Mode
Agile principle 8 is practical: sustainable development. Burnout causes:
- Lower quality,
- Higher defect rates,
- Increased staff turnover.
Exam markers like “sustainable pace” discussions:
- Teams should not accept more work than they can complete.
- WIP limits and realistic sprint capacity help.
Definition of Done vs “Working” vs “Shippable”
A subtle but exam-relevant distinction:
- Done can mean the work meets quality gates.
- Shippable means it’s ready for release to users.
- In many organizations, these differ due to release approvals, compliance, or infrastructure constraints.
A strong exam answer:
- “Agile uses Definition of Done to ensure increments are genuinely complete; release may be separate but should be planned to avoid accumulation of unfinished changes.”
Practical “Agile vs Not Agile” Decision Checklist
To answer “Is this approach Agile?” questions, apply this checklist:
- Are priorities managed through a backlog with continuous refinement?
- Is work delivered in small increments frequently?
- Does the team hold Sprint Reviews or equivalent feedback sessions?
- Is there a regular reflection/improvement loop (Retrospective)?
- Is quality controlled via Definition of Done and engineering practices?
- Does the team respond to feedback by re-prioritizing?
- Are roles understood (PO for value ordering, SM for process facilitation)?
If several items are missing, the approach may be “Agile-branded” but not Agile in substance.
South African University-Level Integration: Putting it All Together with Mini-Scenarios, Exam-Style Questions, and Practical Summaries (UNISA-style “discuss” & “apply” practice)
This final section consolidates learning through scenarios that mirror common exam formats: define, discuss, compare, apply, and critique. It also reinforces that Agile Manifesto principles and practices work together as a system.
Scenario Set 1: Late Requirements and Change Control
Scenario:
A team building a student portal starts Sprint 1 with a clear login requirement. During Sprint 2, the university discovers a new compliance requirement: enhanced audit logging. The stakeholder insists on including it immediately.
Agile interpretation using principles:
- Principle 2: welcome changing requirements, even late
- Principle 4: collaborate daily (or frequent communication)
- Principle 7 and DoD: progress measured by working increments
Scrum response:
- The PO updates Product Backlog ordering (moves audit logging higher)
- Developers assess impact and decide what can be added in the next sprint
- If the audit logging must start sooner, the team may adjust selection for upcoming sprint(s) while protecting sprint goal integrity
Non-agile response (what fails):
- Treat change as a major exception requiring months of approvals
- Freeze scope until a large “end phase”
Exam-style “discuss” answer points:
- Explain trade-offs: rework vs value
- Show how Agile manages change through prioritization and iteration
Scenario Set 2: “Agile” Meetings Without Delivery
Scenario:
A department conducts daily stand-ups and weekly planning meetings, but stakeholders receive nothing demonstrable for 8–10 weeks.
Diagnosis:
- Meetings are not the product; delivery is.
- Principle 7: working product is progress
- Principle 1 and 3: early and continuous delivery and frequent working increments
Likely root causes:
- No Definition of Done
- Lack of CI/testing; work cannot reach “done”
- Sprint Reviews become status reports rather than demonstrations
- Product Owner unavailable, so backlog priorities become unclear
Fixes:
- Establish Definition of Done with clear quality gates
- Adopt CI and automated testing to reduce integration delays
- Ensure Sprint Reviews demonstrate user-relevant increments
- PO ensures backlog items have acceptance criteria and clarity
Scenario Set 3: Scrum When Work Arrives Randomly (and When Kanban Helps)
Scenario:
A team supports production incidents and receives urgent issues unpredictably, such as authentication failures affecting students.
Scrum challenge:
- Sprint goals may be disrupted by urgent work.
- Frequent reprioritization may lead to repeated re-planning.
Kanban advantage:
- Continuous flow and WIP limits handle variability better.
- Incident work can be managed with policies (e.g., “expedite” lane).
Exam compare points:
- Scrum: timebox-based planning and regular review
- Kanban: flow-based work and WIP control
Exam-Style Short Questions (With Strong Marking Points)
Q1: “List and explain the four Agile Manifesto values.”
Marking points:
- Individuals & interactions
- Working software
- Customer collaboration
- Responding to change
Q2: “Explain two Scrum events and how they support Agile principles.”
Strong choices:
- Sprint Review → stakeholder feedback and learning (principles 1–3)
- Sprint Retrospective → inspection/adaptation (principle 12)
- Daily Scrum → collaboration and alignment (principle 4, daily work together)
Q3: “Why is Definition of Done critical in Agile?”
Strong answer:
- Makes “done” measurable and consistent
- Enables working increments as progress
- Reduces hidden defects and rework
- Supports sustainable delivery and technical excellence
Q4: “Compare Scrum and Kanban in terms of planning and progress measurement.”
Strong answer:
- Scrum: fixed sprint planning; progress by completed increments per sprint
- Kanban: continuous planning; progress by flow metrics and delivered work as capacity frees
Practical Summary: Agile Principles → Practices Mapping (A Study Aid)
Use this mapping when writing exam answers that ask “link principles to practices.”
| Agile Principle / Value | Practice Examples | What You Write in Exams |
|---|---|---|
| Responding to change | Backlog refinement, re-prioritization, iterative planning | “Change is managed through learning cycles, not ignored.” |
| Working software as progress | Increment demos, DoD, automated tests | “Progress is tangible and validated.” |
| Customer collaboration | Sprint Reviews, PO availability, workshops | “Stakeholders provide feedback frequently.” |
| Sustainable pace | Capacity planning, WIP limits, realistic commitments | “Delivery must remain maintainable long-term.” |
| Technical excellence | CI/CD, refactoring, code review, test automation | “Engineering quality supports faster, safer delivery.” |
| Simplicity | MVP, reduce batch size, remove unnecessary features | “Maximize work not done by focusing on essentials.” |
“What Counts as Good Agile Practice?” (A Final Consolidation)
Good Agile practice is not one ceremony; it is a system:
- Values define behaviour (collaboration, feedback, quality, adaptability).
- Principles guide decisions (change welcomed, frequent delivery, sustainable pace).
- Frameworks provide structure (Scrum roles/events/artifacts or Kanban flow policies).
- Engineering practices deliver evidence (CI, testing, DoD, refactoring).
- Metrics and reflection ensure improvement (retrospectives, flow/quality measures).
Common Marking Rubric Themes Used by South African Courses
Across UNISA-style and similar project management assessments, examiners often reward:
- Correct definitions (Manifesto values, Scrum roles/events/artifacts)
- Application (use scenarios rather than memorizing words)
- Critique (misuse, risks, limitations, how to mitigate)
- Consistency (clear links between principle → practice → outcome)
- Terminology accuracy (PO vs SM vs Developers; Sprint Review vs Retrospective)
Final Exam Checklist: Agile Manifesto Principles and Practices Summaries (Quick Revision)
Before your exam, ensure you can do the following:
Agile Manifesto
- Explain the four values and the implied trade-offs.
- Describe the intent behind at least 6–12 principles.
- Provide “cause → effect” explanations (e.g., frequent delivery reduces uncertainty).
Scrum
- Name roles: Product Owner, Scrum Master, Developers.
- Explain events: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
- Explain artifacts: Product Backlog, Sprint Backlog, Increment.
- Define Definition of Done and explain why it matters.
Kanban / Flow & Lean
- Describe WIP limits and flow metrics (lead time, cycle time, throughput).
- Compare Scrum (timeboxed planning) with Kanban (continuous flow).
- Connect Lean waste reduction to Agile delivery effectiveness.
Engineering & Quality
- Explain how CI and automated tests support “working software.”
- Describe refactoring as technical excellence.
- Explain how quality gates prevent misleading progress.
Stakeholders & Adaptation
- Explain how collaboration happens (Sprint Reviews, PO feedback, workshops).
- Explain how teams adapt (retrospectives, backlog refinement).
If you can meet every bullet in this checklist, you will be prepared for the most common exam question types on Agile Manifesto Principles and Practices, especially in UNISA-aligned project management and Agile/Scrum content assessments.
