The Exam
Everything in Parts I–XI comes together in one 120-mark, two-hour Canvas quiz on Wednesday 18 November 2026. This Part is the playbook for it: what the paper looks like, how it is marked, how to answer each kind of question, every formula with a worked line, the lists to know cold, a day-by-day plan, and every question of the staff's official practice exam with its answer explained.
- You will know the exam's format, its scoring rules (including how wrong ticks cost marks on multiple-response questions), its time budget and what you may bring.
- You will have an answer skeleton for each question type, and the eight-step method for "evaluate and recommend" case-study questions.
- You will be able to carry out every calculation the course uses, from the critical path to earned value and NPV, with the working the markers want to see.
- You will understand why each official practice-exam answer is right, so that you can reason your way through different questions in the real exam.
The Exam at a Glance exam
You can know every topic in this subject and still lose marks to the format: running out of time, ticking one option too many, or arriving with the wrong notes. This section removes those surprises. Everything in it comes from the Week 12 revision lecture and the exam cover sheet it showed, plus the staff's Ed FAQ (the "Final Exam Megathread" on the Ed discussion board). These replace earlier guesses, which were written before the format was published.
When, where and what kind of exam
The exam is on Wednesday 18 November 2026, 12:30–2:45 pm, at the Royal Exhibition Building (East). The first 15 minutes are reading time: you can read the questions, but you can't type, write or select any option. Then come 2 hours of writing time. An earlier version of the study guide quoted a Canvas window of 12:30–15:15; the lecture's times match 15 minutes' reading plus 2 hours. Your personal exam timetable wins over both, so check it, and contact the university exams team if you have a clash.
The exam is a digital, invigilated, closed-book Canvas quiz. Digital means you sit it on a laptop, in Canvas (the university's learning system), in the exam venue. Invigilated means supervisors watch the room. Closed-book means no books or devices, apart from the notes and the few items the cover sheet allows. The quiz runs inside LockDown Browser, a special browser that locks the laptop so that you can reach nothing but the exam.
A hurdle is a minimum you must reach to pass the subject, whatever your other marks are.
Prepare your laptop by working through the university's LockDown Browser student guide. If you need to borrow a university laptop, request one through the university's central process, not the subject staff, and do it before that process's deadline.
The exam is worth 50% of the subject. The handbook sets two hurdles: at least 25/50 on the exam, and at least 25/50 across the two assignments (A1 and A2) combined. As in any subject, you also need 50/100 overall to pass.
The paper: 120 marks in 120 minutes
The paper is marked out of 120 marks, and you have 120 minutes of writing time, which is one minute per mark. It has two kinds of question.
- About 15–20 multiple-choice and multiple-response questions, worth about 35–45 marks in total. A multiple-choice question (MCQ) has exactly one correct option and is worth 2 marks. A multiple-response question (MRQ) has 2 or 3 correct options and is worth 3 marks.
- Several extended written questions, worth about 75–85 marks. A written question may have several sub-parts, which may build on each other or stand alone. Many are case-study "evaluate and recommend" questions or calculations.
Two marking rules make a big difference. First, a mistake carried forward still earns marks: if you get one sub-part wrong but use that wrong result correctly in the later steps, the later steps still score. Second, the Ed FAQ confirms that every written answer is partially marked. A partly right answer, or a correct method with a slip in the arithmetic, still earns marks, and a blank never does.
How MCQs and MRQs are scored
An MCQ is simple: one correct option, 2 marks, and a wrong answer costs nothing more than a blank. An MRQ is different. It has 2 or 3 correct options, and Canvas lowers your mark for every wrong option you tick. The lecture gives four examples, drawn below.
All four examples fit one rule. The rule is the study guide's inference from the examples, not the lecture's own wording:
MRQ score = (right ticks − wrong ticks) ÷ number of correct options, never below 0 marks = score × 3
So a wrong tick cancels a right one. The practical advice follows directly: tick an option only when you think it more likely right than wrong, and remember that every MRQ has at least two correct options, so a single tick is almost certainly too few.
Pick a question, tick options, and watch the score change under the rule above. The four buttons load the lecture's four examples. (The ticks are marked right or wrong as you go, because this demo is about the scoring, not the content.)
Check yourselfAn MRQ has 3 correct options. You are sure of two options and think a third is about 40% likely to be right. Should you tick the third? And what do you score if you tick it and it is wrong?
Don't tick it. With only your two sure ticks you score 2 ÷ 3 = 67%, or 2 of 3 marks. Ticking a third option that is more likely wrong than right is a bad bet: if it is wrong, the score falls to (2 − 1) ÷ 3 = 33%, or 1 mark; if it is right, it rises to 3 ÷ 3 = 100%. At 40% likely, you lose a mark 60% of the time and gain one 40% of the time. The rule of thumb is to tick only what you think is more likely right than wrong.
What you may bring
The cover sheet allows only the seven blue items in the figure. According to the Ed FAQ, two more things are allowed, shown in amber: the rough paper the invigilators hand out, which you use for working such as a PERT network and must leave behind, and an external mouse and keyboard, as long as the keyboard isn't a loud one. The venue rules are the usual ones, listed in the red strip.
The notes allowance is generous. The two double-sided A4 pages may hold anything you like, in any language, typed, handwritten or drawn. The Ed FAQ adds that there are no restrictions on font, size, spacing, colour, format or word count, that any mix of handwritten, printed and drawn material is fine, and that you may include lecture slides, tutorial slides and screenshots.
Planning your notes sheets
Four A4 sides is a lot of space, so plan them rather than copying the study guide onto them. They help most where memory fails under time pressure. The figure shows one way to arrange the four things the guide recommends; the arrangement is a suggestion, but the contents are the guide's list.
The practice exam, consultations and the day itself
A practice exam in the same format as the final has been on Canvas since the Tuesday of Week 12, in two versions with the same questions: an untimed Canvas quiz, and a version that requires LockDown Browser so that you can get used to working in it. The revision lecture promised only partial solutions, but on 29 October the staff went further and posted a full Practice Exam Guide (Canvas, Modules > Practice Exam), which gives their answer to every question. Sections 12.10 and 12.11 explain each one. The staff warn in both places that rote-learning those answers is likely to attract low marks. The Ed FAQ adds that the final is similar in difficulty to the practice exam, but that its topics and what you are asked to do can change.
Consultations run in SWOTVAC (the study break before exams) and in the week before the exam. An online exam consultation was held on Thursday 29 October, and a Canvas announcement says another session will follow "next week", with details to be posted, so watch Canvas for it.
- A charged laptop with LockDown Browser working, and its charger.
- Your photo ID and your printed notes sheets.
- Pens and pencils for the rough paper.
- An external mouse and a quiet keyboard, if you prefer them.
- Test your Canvas login on campus Wi-Fi beforehand.
Check yourselfWhich of these are true of the SWEN90016 exam? (Select all that apply.)- You may start typing as soon as reading time begins.
- You need at least 25/50 on the exam, whatever your assignment marks.
- Your notes may include printed lecture slides and screenshots.
- A correct method with an arithmetic slip earns no marks.
- Rough paper is provided, and you must leave it behind.
B, C and E. A is false: during the 15 minutes of reading time you can't type, write or select anything. D is false: the Ed FAQ says every written answer is partially marked, so a correct method with a slip still earns marks. B is the exam hurdle, C comes from the Ed FAQ on notes, and E from the Ed FAQ on rough paper.
- Wed 18 Nov 2026, 12:30, Royal Exhibition Building East: 15 min reading (no typing), then 2 h; a closed-book Canvas quiz in LockDown Browser; 50% of the subject with a 25/50 exam hurdle.
- 120 marks: about 35–45 from 15–20 MCQs (2 marks, one answer) and MRQs (3 marks, 2 or 3 answers, wrong ticks cancel right ones), and 75–85 from extended written questions, all partially marked.
- Bring photo ID, pens, a non-programmable calculator and two double-sided A4 pages of notes planned around formulas, lists, skeletons and confusable pairs.
What Is Examinable exam
Revision time is limited, so you need to know where the marks will come from. The course answers that in two ways: an official scope statement from the revision lecture, and a handful of places where the tutorials and assignments point straight at the exam.
The official scope
According to the Week 12 revision lecture, everything covered in the subject is examinable except the Week 11 guest lecture. That means all lecture content, all tutorial content and all assignment-related content. The lecture stresses that lecture and tutorial content both include their case studies: for example PayPal, TaskTidy, CareConnect+ and Coles in the lectures, and Medic, Knight Capital and NovaSuite in the tutorials.
Four places the course points at the exam
Within that scope, the course materials point fairly directly at what the exam will test, in four places.
Take each in turn. Tutorial 1 (T01) asks you to "Document the business drivers for the Medic case study" and labels it an "Intended Testing Area for Final Exam". A business driver is the problem, pressure or opportunity that makes an organisation willing to invest, so expect a question on why a project is undertaken, possibly set on Medic (see Part I and 12.4).
Tutorial 2 (T02) calls for "Critical analysis and justification of an alternate SDLC" for the case, again marked "Final Exam Testing Area". An SDLC (software development lifecycle) is a process model such as waterfall, spiral or Scrum. Expect to recommend one SDLC and link its features to the facts of the case (Part II, Part III).
The A1 specification says that A1's case-analysis skills "will be assessed again in controlled exam conditions". Expect A1's chain of questions applied to a new case: the goals, then the setbacks, then how the SDLC contributed to them, then how the same SDLC could have been done better, and finally an alternative SDLC.
Finally, the Week 1 slides (W01a) say the exam "Covers … lectures, tutorials, project", and the revision lecture confirms that all assignment-related content is examinable. That makes the tutorial Medic exercises exam practice, and it means there may be questions on how your own team ran Scrum (12.8). Every Part from I to XI includes a Medic application, and Part XI also works the T10 NovaSuite case.
Medic is the tutorials' running case. Surgeons at the Royal Victorian Eye and Ear Hospital (RVEEH) want a virtual surgery simulator for practising cochlear-implant and temporal-bone operations, because quality cadavers for practice are scarce. The software uses stereoscopic 3D and haptics (touch feedback), both new to the development team of 12 developers and 2 managers, and is handed over to the hospital's IT at the end. Its seven features (load a model, stereoscopic rendering, 3D and microscope viewing, select a procedure and configure the haptics, perform the procedure, save and restore, replay and pause) are its scope.
The learning outcomes
The subject's intended learning outcomes (ILOs), stated in W01a and paraphrased here, are what the exam is designed to test. The table maps each onto the Parts of this site.
| # | Intended learning outcome (paraphrased) | Where this site teaches it |
|---|---|---|
| 1 | Critically evaluate and apply established processes and practices | Parts II, III, VI, XI; section 12.4 |
| 2 | Navigate team dynamics and communicate professionally | Part V (teams, communication, conflict); Part IX |
| 3 | Strategise and execute project planning and management | Parts I, V (the plan), VI, VIII |
| 4 | Evaluate and address project risks | Part IV; the spiral model in Part II |
| 5 | Manage project activities to ensure a quality product | Parts VII, X |
| 6 | Employ PM processes and techniques | Parts I, VIII, X, XI |
The outcomes say "critically evaluate" and "apply", and A1 says "justify". Those verbs mean that most marks are for applying concepts to a situation, not reciting them. A perfect definition earns little on its own; the same definition used to explain a fact in the case earns the marks.
The revision lecture's topic checklist
The revision lecture ends with a reminder of the topics, week by week. It says the list is not exhaustive and doesn't mention everything examinable. Use it to judge what you do and don't know well, then go back to each lecture and tutorial (here, each Part) for the detail. The table condenses the list.
| Week | Topics on the revision list | Part |
|---|---|---|
| 1 | Projects and why organisations use them; foundations of project management; the project manager's skills, responsibilities and activities; why projects fail or succeed; project screening; project initiation and the business case; investment techniques and financial models; the project charter | I |
| 2 | Formal process; defined vs empirical process control; the prehistory of SDLCs; waterfall, incremental, rapid prototyping and spiral; the Agile Manifesto and principles; Kanban, XP and Scrum, with Scrum Masters, Product Owners and Development Teams; the PayPal case | II, III |
| 3 | Risk vs uncertainty; risk management planning and the plan document; kinds of risk (project, product, business); identification by pondering, interviewing, brainstorming, checklists and Delphi; qualitative and quantitative analysis and the risk matrix; responses; monitoring and control; risk management in Agile; SWOT | IV |
| 4 | The Project Management Plan vs the charter; documentation in Agile; software project issue management and change requests; stakeholder analysis, registers and engagement levels; the power–interest grid; teams and groups, the characteristics of bad teams, types of team and Scrum teams; communication management and the communication plan | V (change requests also X) |
| 5 | Agile planning and estimation: sprint planning, MoSCoW, scope and timeboxing, requirements in traditional vs agile processes, user stories and epics, task breakdown, the product increment, acceptance criteria and the DoD; the product backlog, story points and velocity; estimation techniques; sprint vs release burndown; planning artefacts and releases | VI |
| 6 | What software quality is and what it costs; quality assurance (V&V, types of testing); quality planning and the Software Quality Plan; quality control through technical, business and management reviews; standards (ISO, document, process and product standards) and CMMI | VII |
| 7 | The project schedule and its charts; the five steps: WBS, task network, effort and time estimates (the Putnam–Norden–Rayleigh curve, and three-point estimating with triangular and PERT distributions), resource allocation and effort validation, and the schedule as a PERT chart; tracking and control with earned value, schedule variance and cost variance | VIII |
| 8 | Ethics in computing practice; micro- and macro-ethical issues; example contexts; ethical challenges for graduates in industry; the ACS Code of Ethics; the ethical responsibilities of IT professionals; handling ethical dilemmas | IX |
| 9 | The role of configuration management (processes, repositories, tools); the goals of the CM process; its tasks of identification, version control, change control, configuration auditing and status reporting | X |
| 10 | Essential SAFe; the ART roles (Release Train Engineer, Product Management, System Architect, Business Owners); the key areas: PI Planning, the ART, roles and responsibilities, Scrum of Scrums, the Program Backlog, the System Demo and the I&A workshop | XI |
- The list calls the highest level of stakeholder engagement Champion. That is the W04 slides' "Champion / Leading", the top of the five engagement levels in Part V; the names mean the same thing.
- Software project issue management with change requests (Week 4) has no slides of its own in the 2026 decks. Know the basic idea: change requests and integrated change control (Part V, Part X), and the difference between a risk (might happen) and an issue (is happening) (Part IV).
- The Putnam–Norden–Rayleigh (PNR) curve (Week 7) has no slides either. Part VIII explains it from Pressman, the textbook the W07 slides cite: compressing a schedule raises effort very steeply (its formula is in section 12.5).
Check yourselfA friend says: "I'll skip the case studies, they're just stories; and I'll skip the guest lecture too." Which half of that plan is safe?
Only skipping the guest lecture. The revision lecture says the Week 11 guest lecture is the one thing not examinable, and it stresses that lecture and tutorial content include their case studies (PayPal, TaskTidy, CareConnect+, Coles, Medic, Knight Capital, NovaSuite and others). Case facts are exactly what written answers must use.
Check yourselfWhich course document labels "document the business drivers for the Medic case study" as an exam testing area, and what is a business driver?
Tutorial 1 (T01), which calls it an "Intended Testing Area for Final Exam". A business driver is the problem, pressure or opportunity that makes an organisation willing to invest in a project: for Medic, above all the shortage of quality cadavers for surgical practice (all six drivers are in 12.4).
- Everything is examinable except the Week 11 guest lecture, and that includes every lecture and tutorial case study and the assignment content.
- T01 (business drivers), T02 (one justified alternative SDLC), A1 (the case-analysis chain) and W01a (the project) point straight at likely questions.
- The outcomes' verbs, "evaluate", "apply" and "justify", mean marks go to applying concepts to facts, not reciting them.
Question Types and How to Answer Them exam
Knowing the content is half the job; the other half is turning it into marks in a plain text box, against the clock. This section gives the time rule, what the markers say they want, the habits that suit a typed exam, and a skeleton for each type of question: the order in which to write your answer.
The marks-to-time rule
The paper is 120 marks in 120 minutes, and the revision lecture tells you to use one minute per mark to decide how long to spend on each question. Hold about 10 minutes in reserve for checking and unfinished parts, which leaves a little over 0.9 minutes per mark. The other half of the rule is what a mark buys: one mark is roughly one distinct, correct, applied point, which takes one or two sentences (25–40 words). So a 6-mark question wants about six points.
What the markers want
The Week 12 revision lecture is explicit. Written questions often call for short answers that show a meaningful comprehension of the subject. A bare definition doesn't show that: a definition-level answer attracts low marks unless the question explicitly asks for a definition. Explain and justify every point, and build the answer from the information in the question's scenario or case study, adapted to that scenario, rather than from generic theory. Several bullet points are an acceptable way to give a short, concise answer, as long as each one explains rather than merely names.
The staff's official Practice Exam Guide repeats these warnings and adds two more: answers rote-learned from the practice exam are likely to score low, and when a question asks you to base your response on the scenario you may quote the relevant parts of it, which is often the most convincing evidence you can give (12.10).
Here is the difference on a "comment on a statement" question, using the documentation ideas from Part V.
"Agile teams don't document." Comment.
The Agile Manifesto values working software over comprehensive documentation. Agile teams focus on delivering software, so they document less.
No verdict, one-sided, and it restates the claim. At most a mark.
Mostly false. The Manifesto values working software over comprehensive documentation, not instead of it. Agile teams still document for organisational memory, for external groups, for audit and compliance, and to pin down complex ideas. What changes is how: just barely good enough, just in time, and kept living. The claim would hold only for throwaway work with no auditors or maintainers. So agile teams document less up front, but not nothing.
Habits for a typed exam
A few habits suit a plain answer box.
- Use the 15 minutes of reading time to read the written questions' scenarios, note which facts each part will need, and plan your order and timings. You can't type or select anything until writing time starts.
- The Canvas answer box can be resized from its bottom-right corner or switched to fullscreen (Ed FAQ), so enlarge it for the long written answers and you will see your whole answer at once.
- Label the parts (a), (b) and so on, and write short bullets with one point each. Don't retype the question.
- When a sub-part builds on an earlier one, use your earlier answer even if you doubt it, and show the steps; a mistake carried through correctly still earns marks.
- Don't rely on tables rendering in a quiz box. Arrow lines work anywhere, for example "Issue → SDLC feature → why it helps".
- To put a diagram into text, write each node as a line (figure below).
- For calculations, give the formula, then the substitution, then the result with units, then a one-line meaning. Round only at the end, and state your assumptions.
- Use the reserve time to fill every part, because a blank scores zero.
An answer skeleton for each question type
The figure gives each question type its skeleton, read left to right as the order to write in. The table after it adds an example of each type and the mistakes that lose marks on it.
| Type (example) | Answer skeleton | What loses marks |
|---|---|---|
| MCQ (2 marks; one correct option) | Rule out the options that belong to another concept or level (team vs ART, risk vs issue) → choose → move on | Overspending time; misreading "primary", "not" or "best"; leaving it blank, since a blank and a wrong answer both score zero |
| MRQ (3 marks; 2 or 3 correct options) | Judge each option on its own as true or false → tick only the ones you would bet on → expect 2 or 3 ticks, though practice Q16 had 4 (12.10) | A doubtful extra tick: each wrong tick cancels a right one |
| Define ("What is a baseline?") | Course definition → short example (Medic if possible) → for 2+ marks, why it matters or its contrast. Give a bare definition only when the question asks for one | Vague paraphrase; a definition where the question wanted application; confusing pairs (risk/issue, version/variant, verification/validation, incremental/evolutionary) |
| List and explain ("Explain Scrum's pillars") | The number asked; each: name, what it is, why or how, example | Wrong count; bare names; items from another list ("contingency" as a risk strategy, Part IV) |
| Compare ("RTE vs Scrum Master") | Define each in a line → 3–5 dimensions, both sides per line ("Scope: whole ART vs one team") → when to use which | Two separate descriptions; no criteria; no verdict |
| Calculate (CPM, EV, RE/RRL, velocity, NPV) | Formula → working → answer with units → interpretation → assumptions | No working; reversed formulas (CV = AC − EV); no interpretation; early rounding |
| Scenario: evaluate and recommend | Section 12.4: facts → cause → practice → effect chains → one SDLC linked feature by feature → limitations → verdict | Generic "agile is flexible"; several SDLCs (T02: one); no case facts; no trade-off |
| Ethics scenario | Part IX's method: facts → stakeholders (incl. absent ones) → issues → ACS clause + fact + consequence → options → decision → prevent | Values without facts; "my manager told me to"; pre-2023 values; ignoring the public |
| Comment on a statement ("Agile teams don't document") | Verdict → what is right → what is wrong, with theory and evidence → when it would hold → conclusion | No verdict; one-sided; restating the claim |
Across all the types, the answers that lose most are those that ignore the scenario's facts, answer at definition level, or run out of time. The skeletons above are built to prevent all three.
A few terms in the table, defined: an ART (Agile Release Train) is SAFe's team of agile teams, and the RTE (Release Train Engineer) is its servant leader, the ART-level counterpart of a team's Scrum Master (Part XI). A baseline is a reviewed, agreed version of a work product that changes only through formal change control (Part X). The ACS Code is the Australian Computer Society's Code of Professional Ethics; the 2023 version has four values (Part IX).
Check yourselfA written part is worth 8 marks. Roughly how long should you spend, and how many points should your answer make?
At about 0.9 minutes per mark (one minute per mark, less the 10-minute reserve), spend about 7 minutes. One mark is roughly one distinct, correct, applied point, so aim for about eight points of one or two sentences each.
Check yourself"Compare the Release Train Engineer with the Scrum Master." A student writes one paragraph on each role. What is wrong, and what should the answer look like?
Two separate descriptions are the classic mark-loser on a compare question: the marker has to do the comparing. The skeleton is: define each in a line; then 3–5 dimensions, each with both sides on one line, such as "Scope: the whole ART vs one team"; then say when each applies. A verdict line ties it off.
Check yourselfWhich of these habits suit the typed Canvas exam? (Select all that apply.)- Draw your PERT network as a table in the answer box.
- Use your earlier sub-part's answer even if you doubt it, and show the steps.
- Retype each question before answering, so the marker knows what you're answering.
- Write each network node as one line of text.
B and D. A is risky because tables may not render in a quiz box; use arrow lines or one line per node. C wastes time: label the parts (a), (b) instead.
- One minute per mark, with about 10 minutes in reserve; one mark ≈ one distinct, correct, applied point of 25–40 words.
- Markers reward explanation built on the scenario's facts; definition-level answers score low, and quoting the scenario is good evidence.
- Each question type has a skeleton; calculations always go formula → substitution → result with units → meaning.
The Case-Study Analysis Method exam
The biggest written questions hand you a case, a project that went wrong, and ask you to explain why and what would have worked better. Without a method, answers drift into generic claims such as "agile is more flexible", which score low. This method combines A1's question chain (its Q1–Q3) with T02's "good argument" pattern, and it is shaped by what A1's top rubric bands reward: specific evidence, reasoned links from cause to outcome, at least three issues linked to features of the alternative SDLC, and limitations weighed against benefits. Your evidence is the case text itself, so quote its facts and numbers.
The eight steps
- Eight steps, taken in order. The first three understand the case, the middle three diagnose it and fix it within its own model, and the last two prescribe an alternative and weigh it.
- 1 · Goals and business drivers (A1 Q1; T01). State the problem or opportunity, who benefits, and the measurable goal. Remember that drivers are not features: "a shortage of cadavers" is a driver, "a replay function" is scope.
- 2 · Characteristics. Describe the project's characteristics, challenges, risks and constraints, as T02 asks, by running Part II's checklist: requirements stability, novelty, criticality, customer availability, size, early delivery, team experience, contract and handover.
- 3 · SDLC used or inferred. If the case doesn't name the SDLC, infer it and say that you have (A1). The waterfall markers are a specification signed off up front, sequential phases, testing last and a single delivery. The agile markers are sprints, a backlog, a Product Owner (PO) and demos.
- 4 · Setbacks, with evidence. Name each setback, whether a delay, a percentage overrun, a scope cut, a quality failure or a cancellation, and give the project's CHAOS category: the Standish Group's three outcomes, successful, challenged (late, over budget or cut) or failed (Part I).
- 5 · How the process contributed (rubric Q2(ii)). Write one chain per issue, running from cause to SDLC practice to effect. Two or three precise chains beat a vague paragraph.
- 6 · Better application of the same SDLC (rubric Q2(iii)). Propose one fix per chain, staying within the same model. Typical fixes are Royce's fixes, phase-gate reviews, a risk register, change control, early test planning and stakeholder engagement. For a failed agile project, the fixes are an empowered PO, a Definition of Done that includes testing, and reviews with real users.
- 7 · One alternative SDLC (rubric Q3(i)–(ii); T02). For each chain from step 5, give the feature of the new SDLC and how it would have prevented or reduced that issue. Use Part II's pattern: start from a project fact, state the need it creates, name the SDLC characteristic that meets the need, then give its effect and the trade-off.
- 8 · Limitations and residual risks (rubric Q3(iii)). Say what the new SDLC needs that the case may lack (Scrum needs an available PO and a flexible contract; spiral needs risk expertise), how you would handle that, and why the benefits still win. End with a one-sentence verdict.
Before you start typing, plan with a quick grid whose columns are issue, evidence, causing practice, same-SDLC fix and alternative-SDLC feature. One row per issue gives you steps 5, 6 and 7 at a glance. Here is the grid for the worked case below.
| Issue | Evidence (quote it) | Causing practice | Same-SDLC fix | Alternative-SDLC feature (Scrum) |
|---|---|---|---|---|
| 1 · Users' misfit found late | 40% of builders abandon in the month-13 pilot | Spec frozen with planners only; no software shown until UAT | Builders and residents in requirements reviews; UI mock-up before sign-off | Sprint Reviews with real users from the first sprints |
| 2 · Integration risk deferred | Database link first exercised in month 11; timeouts at 30 users | Testing last | "Do it twice": pilot and load-test the interface in design | Risk-first backlog, a spike, load test in the DoD |
| 3 · Slow, costly change | Fee-rule variation took months to approve | Frozen spec + fixed price, no change path | Change control board with fixed turnaround, pre-priced variations | Ordered backlog: new rules re-ordered at Sprint Planning |
For Medic, the right answer depends on which facts you use. In the original case (T02) the senior doctors are busy, and on those facts Part II argues for spiral. The addendum makes liaison surgeons available daily, and on those facts Part III argues for adapted Scrum. So say which facts you are relying on.
Worked model answer: a new scenario
The guide's model answer below is the method run on a fresh case. Read the case, try parts (a)–(c) yourself, then compare.
A regional council contracts a vendor, at a fixed price of $3.2M over 14 months, to replace paper building-permit applications with an online portal linked to its 1990s property-rates database. Five months of workshops with council planning officers produce a 400-page specification, signed off before design starts. Builders and residents, who will use the portal, are not consulted. Coding starts in month 8. The rates-database link is first exercised at system integration in month 11. Also in month 8, new state legislation changes permit-fee rules; the vendor prices the change as a contract variation, and the council takes months to approve it. User acceptance testing in month 13 finds that the database interface times out at 30 concurrent users, and in a pilot 40% of builders abandon their applications part-way. The portal goes live 9 months late at $5.1M, without online payment, which was cut to save money.
(a) What were the project's goals? (b) Evaluate how the process contributed to the setbacks and how it could have been better applied. (c) Recommend and justify an alternative SDLC.
- The plan: a fixed-price contract, $3.2M over 14 months, for an online permit portal linked to a 1990s rates database.
- Months 0–5: workshops with planning officers only produce a 400-page specification, signed off before design starts. The portal's real users, builders and residents, are never asked.
- Design, then coding from month 8. In the same month new state legislation changes the permit-fee rules. The vendor prices it as a contract variation, and the council takes months to approve it, while coding continues against the old rules.
- Month 11: system integration. The rates-database link is exercised for the first time, eleven months in.
- Month 13: user acceptance testing (UAT) finds the database interface times out at 30 concurrent users, and in a pilot 40% of builders abandon their applications part-way.
- The portal goes live 9 months late (23 months instead of 14) at $5.1M, which is (5.1 − 3.2) ÷ 3.2 = 59% over budget, and online payment was cut. In CHAOS terms it is challenged: delivered, but late, over budget and with less scope.
- The three gold badges are the three issues the answer builds chains on: 1 the users' misfit found only at UAT, 2 the integration risk deferred to month 11, and 3 a frozen specification meeting changing law. All three are feedback that arrived months late.
(a) Goals. The council wanted to cut the cost and delay of processing paper permits, and to give builders and residents online lodgement and payment at any hour. The portal also had to apply the state's permit rules correctly and reuse the existing rates data instead of re-keying it.
Characteristics. This is a public-sector project on a fixed price, with a legacy system to integrate and regulation that is changing. It has several user groups (planners, builders and residents), most of whom are not IT experts.
(b) SDLC used (inferred). The case doesn't name it, but the practices are waterfall: a complete specification signed off before design, sequential phases (coding from month 8, integration in month 11, UAT in month 13), a single delivery, and a fixed-price contract that treats every change as a variation.
Setbacks. The portal went live nine months late (23 months instead of 14) and 59% over budget ((5.1 − 3.2) / 3.2), and online payment was cut. There was also a usability failure (40% abandonment) and a performance failure (timeouts at 30 users). In CHAOS terms the project was challenged.
How the process contributed.
- Requirements were frozen with one stakeholder group, so the misfit was only found at UAT. Only planners were consulted, and waterfall shows users no working software until acceptance testing. The usability problem therefore surfaced in month 13, when rework costs most (Part VII, the cost of quality).
- Integration risk was deferred, which forced late rework. The legacy database was first exercised in month 11. Royce warned that when testing comes last, timing and capacity are experienced for the first time, and failures then force redesign (Part II).
- A frozen specification and a fixed price met changing law, so change was slow and costly. With no agreed change path, the variation stalled while coding continued against outdated fee rules.
Better use of waterfall.
- Apply Royce's "involve the customer" by putting builders and residents into the requirements reviews, with a UI mock-up review before sign-off.
- Apply Royce's "do it twice" by piloting and load-testing the database interface during design, against performance targets written into the specification (V-model test planning, Part II).
- Start a risk register (Part IV) with "legislation may change" and "legacy interface may not scale" as high-RE risks, each with an owner, triggers and contingencies, such as a caching layer.
- Agree a change control board with a fixed turnaround and pre-priced variation rates (Part X), and use phase-gate reviews to re-check the business case (Part I).
(c) Recommendation: Scrum. All three root causes were late feedback, which an empirical process is designed to remove (Part II). Each Scrum feature below answers one of the issues.
- Sprint Reviews with real users (issue 1). Builders would try a working lodgement form in the first few sprints, so the 40% abandonment would show up in month 2, not month 13 (Agile principles 1 and 3).
- A risk-first backlog, spikes and a strict DoD (issue 2). The PO orders the database interface early as a high-risk item. A spike, and a Definition of Done that includes a load test against the real database, then expose the timeouts in the first sprints (Part IV, Part VI).
- An ordered backlog that absorbs change (issue 3). The new fee rules become backlog items that the PO re-orders at the next Sprint Planning, instead of a variation to a frozen specification. This is responding to change over following a plan.
- Value-ordered releases (the scope cut). Payment, a Must, ships in an early release, so if money runs out it is the Could-haves that are cut, not payment (Part VI).
Limitations.
- A fixed-price, fixed-scope public contract fits Scrum badly, so use a staged or time-and-materials contract with a budget per release (Part IX).
- Scrum needs an empowered, available PO. Nominate one planner with decision authority, and bring builders to the reviews.
- Permit decisions are legal records, so audit trails and handover documents must be in the DoD (Part V).
- Scrum exposes the legacy-database risk early but doesn't remove it, so the risk stays on the register.
Verdict. Scrum, with these safeguards. Every setback came from feedback arriving months late, and short sprints with user reviews and risk-first ordering cut that delay to weeks.
Some terms used above, briefly: a spike is a short, timeboxed investigation to reduce a risk or an unknown; the Definition of Done (DoD) is the team's checklist every backlog item must meet before it counts as finished; RE (risk exposure) is probability × impact; MoSCoW sorts requirements into Must, Should, Could and Won't (this time). Each is taught in full in the Part linked beside it.
Worked short answer: Medic business drivers exam
"Document the business drivers for the Medic project." (T01, flagged as an exam testing area.) A business driver is the problem, pressure or opportunity that makes an organisation willing to invest. The Medic case gives six.
- Shortage of quality cadavers. There are not enough quality cadavers for practising cochlear-implant and temporal-bone surgery; this is the case's problem statement.
- Criticised training model. The apprenticeship model gives too little focused practice and too narrow a caseload, with few non-standard cases.
- Patient safety and quality of care. Both suffer when surgeons are under-practised.
- Medical indemnifiers. They are exposed to claims arising from poorly trained surgeons. (An indemnifier is the insurer that covers doctors against negligence claims.)
- Implant manufacturers. They suffer from the public's perceived risk.
- The client surgeons' standing. Cutting-edge training enhances their reputation and RVEEH's training capacity.
Check yourselfA case study never names its SDLC, but describes a requirements document signed off in month 3, coding from month 6, testing in the last two months and a single launch. What should step 3 of your answer say?
Say that you infer waterfall and say why: a specification signed off up front, sequential phases, testing last and a single delivery are the waterfall markers. A1 rewards stating that the SDLC is inferred rather than pretending the case named it.
Check yourselfFor step 7, a student writes: "Scrum is better because it is flexible, iterative and customer-focused." Rewrite it to score.
Tie each feature to one issue from step 5, in the pattern fact → need → characteristic → effect + trade-off. For CityPermits: "Builders were never consulted and 40% abandoned the pilot in month 13 (fact). The team needed user feedback early (need). Scrum's Sprint Reviews put working software in front of real builders every sprint (characteristic), so the abandonment would have shown in month 2 (effect), at the cost of builders' time each sprint (trade-off)." Repeat for at least three issues.
Check yourselfWhich of these belong in an answer to "Document the business drivers for Medic"? (Select all that apply.)- The shortage of quality cadavers for surgical practice
- Stereoscopic rendering of the temporal bone
- Medical indemnifiers' exposure to claims
- Replay and pause of a recorded procedure
- Implant manufacturers' suffering from perceived risk
A, C and E. B and D are two of the seven features, which are scope, not drivers. Drivers are the reasons to invest; features are what gets built.
Check yourselfCityPermits was budgeted at $3.2M and cost $5.1M. Show the overrun calculation and give the CHAOS category.
overrun = (actual − estimate) ÷ estimate
= (5.1 − 3.2) ÷ 3.2 = 1.9 ÷ 3.2 = 0.59 → 59% over budgetThe portal was delivered, but late, over budget and without online payment, so it is challenged, not failed (a failed project is cancelled or never used).
- Eight steps: goals → characteristics → SDLC (inferred if need be) → setbacks with numbers → cause–practice–effect chains → same-SDLC fixes → ONE alternative linked feature by feature → limitations and a verdict.
- Quote the case's facts and numbers; link at least three issues to features; plan with an issue/evidence/practice/fix/feature grid.
- Business drivers are reasons to invest (Medic has six), not features; for Medic, say which facts you rely on, because they decide between spiral and adapted Scrum.
Calculation Drill Sheet exam
Calculation questions are the most reliable marks on the paper: the method is fixed, the working is visible, and partial marking rewards a correct method even when an answer slips. The risk is forgetting a formula, or getting one backwards, under pressure. This section puts every formula in the course on one page with a worked line each, then drills them with seven practice problems.
Every formula on one page
Watch the details that are easy to get backwards: the forward pass takes the max EF of the predecessors and the backward pass the min LS of the successors, and a negative variance or an index below 1 is bad. Rows marked "older" are older exam topics that are not in the 2026 slides (Part VIII). The worked lines come from the practice problems below where possible; the others use small illustrative numbers.
| Topic | Formula or rule | Worked line | Part |
|---|---|---|---|
| Overrun % | (actual − estimate) ÷ estimate | (3.1 − 2.0) ÷ 2.0 = 55% | I |
| Weighted scoring | Σ(weight × score), weights sum to 1 | 0.5×8 + 0.3×6 + 0.2×5 = 6.8 | I |
| Discounting | DF = 1/(1 + r)t; PV = FV × DF; year 0 is not discounted | DF(2, 10%) = 1/1.1² = 0.8264; 110 × 0.8264 = 90.91 | I |
| NPV | Σ(benefitst − costst) × DFt; accept if > 0 | 445.2 − 395.1 = +50.1 → accept | I |
| ROI (slides) | (Σ disc. benefits − Σ disc. costs) ÷ Σ disc. costs; compare with the hurdle (11–14%) | 50.1 ÷ 395.1 = 12.7% | I |
| Payback | years before break-even + unrecovered ÷ net flow in break-even year (discounted: use discounted flows) | 2 + 110/130 = 2.85 years | I |
| Risk exposure | RE = P × I (expected loss); ΣRE sizes a contingency reserve | 0.3 × $40,000 = $12,000 | IV |
| Risk reduction leverage | RRL = (REbefore − REafter) ÷ response cost; > 1 worthwhile; pick the highest | (15,000 − 3,000) ÷ 6,000 = 2.0 | IV |
| Communication channels | n(n − 1)/2; adding one person to n people adds n channels | 12 × 11 ÷ 2 = 66 | V |
| Velocity | V = Done SP ÷ sprints; capacity estimate = people × SP/day × days | (34 + 41 + 38) ÷ 3 = 37.7 SP/sprint | VI |
| Delivery forecast | sprints = remaining SP ÷ V, rounded up | 147 ÷ 37.7 = 3.9 → 4 sprints | VI |
| Burndown | ideal burn = committed SP ÷ days; remaining falls only when items are Done | 38 ÷ 10 = 3.8 SP/day | VI |
| Cost of quality | conformance (prevention + appraisal) + nonconformance (internal + external failure) | (10 + 20) + (15 + 30) = $75k | VII |
| QA metrics | defect density = defects ÷ KLOC; removal efficiency = found before release ÷ all; leakage = escaped to a stage ÷ caught before it | 30 ÷ 12 KLOC = 2.5/KLOC; 90 ÷ 100 = 90% | VII |
| Three-point estimate | PERT TE = (O + 4M + P)/6; triangular (O + M + P)/3; σ = (P − O)/6, add variances along a path (not in slides) | C: (4 + 24 + 14)/6 = 7; triangular 24/3 = 8; σ = 10/6 = 1.67 | VIII |
| PNR curve | Ea = m × (td/ta)4; below ≈ 0.75 td is the "impossible region" (Pressman; revision list) | ta = 0.8 td: 1.25⁴ = 2.44 × the effort | VIII |
| Staffing | people = effort ÷ duration (Brooks: not interchangeable) | 36 pm ÷ 9 months = 4 people | VIII |
| Forward pass | ES = max EF of predecessors; EF = ES + D | E: ES = max(5, 6) = 6; EF = 6 + 9 = 15 | VIII |
| Backward pass | LF = min LS of successors; LS = LF − D | D: LF = min(6, 16) = 6; LS = 6 − 2 = 4 | VIII |
| Float | TF = LS − ES = LF − EF; FF = earliest ES of successors − EF; critical ⇔ TF = 0 | B: TF = 1 − 0 = 1; FF = 6 − 5 = 1 | VIII |
| Crashing | slope = (crash − normal cost) ÷ (normal − crash duration); crash the cheapest critical option while slope < indirect cost/day; total = direct + indirect × days | (2,600 − 2,000) ÷ (6 − 4) = $300/day < $550 | VIII |
| EV inputs | PV = budget of work scheduled; EV = Σ(budget × % complete); AC = actual cost | EV = 100 + 0.6×150 + 0.1×250 = 215 | VIII |
| Variances | SV = EV − PV; CV = EV − AC (negative is bad) | SV = 215 − 200 = +15; CV = 215 − 250 = −35 | VIII |
| Indices | SPI = EV/PV; CPI = EV/AC (below 1 is bad) | SPI = 1.075; CPI = 0.86 | VIII |
| EV forecasts | ETC = (BAC − EV)/CPI; EAC = AC + ETC = BAC/CPI; VAC = BAC − EAC; duration ≈ planned ÷ SPI | EAC = 250 + 285/0.86 = 581.4 | VIII |
| COCOMO (older) | E = a × KLOCb; D = 2.5 × Ec; organic a, b, c = 2.4, 1.05, 0.38 | 10 KLOC: E = 2.4 × 101.05 = 26.9 pm; D = 2.5 × 26.90.38 = 8.7 months | VIII |
| Function points (older) | FP = UFP × VAF, VAF = 0.65 + 0.01 × ΣGSC; Mark II = 0.44 × inputs + 1.67 × entities + 0.38 × outputs | UFP 200, ΣGSC 45: VAF 1.10 → 220 FP | VIII |
| WSJF | cost of delay ÷ job size; CoD = value + time criticality + risk reduction/opportunity enablement | X: 20 ÷ 5 = 4.0 | XI |
DF discount factor; PV/FV (in discounting) present/future value; NPV net present value, today's value of all future net flows; ROI return on investment; RE risk exposure; RRL risk reduction leverage; SP story points, relative units of effort; V velocity, Done story points per sprint; KLOC thousand lines of code; O, M, P optimistic, most likely and pessimistic estimates; PNR Putnam–Norden–Rayleigh (Ea effort at actual duration ta, m effort at the nominal duration td); pm person-months; ES/EF/LS/LF early start/finish and late start/finish; TF/FF total and free float (slack); PV (in earned value) planned value; EV earned value; AC actual cost; BAC budget at completion; SV/CV schedule/cost variance; SPI/CPI schedule/cost performance index; ETC/EAC/VAC estimate to complete, estimate at completion, variance at completion; UFP/VAF/GSC unadjusted function points, value adjustment factor, general system characteristics; WSJF weighted shortest job first; CoD cost of delay.
- CV = EV − AC, never AC − EV. EV comes first in every variance and on top of every index, so positive or above 1 is always good news.
- Forward pass takes the max (a task waits for its slowest predecessor); backward pass takes the min (a task must finish in time for its most urgent successor).
- Delivery forecasts round up: 3.9 sprints is 4 sprints, because a part-sprint still has to be held.
- Year 0 is not discounted, and ROI uses discounted flows.
P1. Three-point estimates and the critical path
The problem. Each task is given as (predecessors; O, M, P in days): A (none; 2, 3, 10), B (none; 3, 5, 7), C (A; 4, 6, 14), D (A; 1, 2, 3), E (B, D; 5, 8, 17), F (C; 2, 4, 6), G (E, F; 3, 3, 9), H (D; 1, 3, 5). (a) Find the PERT durations. (b) Find ES, EF, LS, LF, and total and free float. (c) Identify the critical path(s). (d) Give the effect of C slipping 2 days, and of B slipping 3 days. (e) Which one task would you shorten by a day?
The critical path is the longest path through the network: its tasks have zero slack, so any delay to one of them delays the whole project. Total float (slack) is how far a task can slip without delaying the project; free float is how far it can slip without delaying any successor's early start.
- The network, drawn from the predecessor column: one node per task, an arrow from each predecessor, and Start and Finish nodes. B has no predecessor; E waits for both B and D; G waits for both E and F.
- (a) PERT durations with TE = (O + 4M + P) ÷ 6: A (2 + 12 + 10) ÷ 6 = 24/6 = 4; B 30/6 = 5; C (4 + 24 + 14) ÷ 6 = 42/6 = 7; D 12/6 = 2; E (5 + 32 + 17) ÷ 6 = 54/6 = 9; F 24/6 = 4; G 24/6 = 4; H 18/6 = 3.
- Forward pass, left to right: ES = the largest EF of the predecessors, EF = ES + duration. A and B start at 0: A 0–4, B 0–5. C and D both follow A, so both start at 4: C 4–11, D 4–6.
- E has two predecessors, B (EF 5) and D (EF 6). ES takes the max: ES = max(5, 6) = 6, so E runs 6–15. F follows C: 11–15. H follows D: 6–9.
- G waits for E (EF 15) and F (EF 15): ES = max(15, 15) = 15, EF = 19. Finish waits for G (19) and H (9), so the project takes 19 days.
- Backward pass, right to left: LF = the smallest LS of the successors, LS = LF − duration. G and H both feed Finish, so LF = 19: G 15–19, H 16–19. E and F both feed only G (LS 15): E 6–15, F 11–15.
- D feeds E (LS 6) and H (LS 16), so LF = min(6, 16) = 6, LS 4. C feeds F: 4–11. B feeds E: LF 6, LS 1. A feeds C (LS 4) and D (LS 4): LF = min(4, 4) = 4, LS 0.
- Slack (total float) = LS − ES: B 1 − 0 = 1; H 16 − 6 = 10; every other task 0. The zero-slack tasks form two critical paths of 19 days: A–C–F–G (4 + 7 + 4 + 4) and A–D–E–G (4 + 2 + 9 + 4). B–E–G takes 18 days and A–D–H 9.
| Task | O, M, P | TE | ES | EF | LS | LF | TF | FF |
|---|---|---|---|---|---|---|---|---|
| A | 2, 3, 10 | 4 | 0 | 4 | 0 | 4 | 0 | 0 |
| B | 3, 5, 7 | 5 | 0 | 5 | 1 | 6 | 1 | 1 |
| C | 4, 6, 14 | 7 | 4 | 11 | 4 | 11 | 0 | 0 |
| D | 1, 2, 3 | 2 | 4 | 6 | 4 | 6 | 0 | 0 |
| E | 5, 8, 17 | 9 | 6 | 15 | 6 | 15 | 0 | 0 |
| F | 2, 4, 6 | 4 | 11 | 15 | 11 | 15 | 0 | 0 |
| G | 3, 3, 9 | 4 | 15 | 19 | 15 | 19 | 0 | 0 |
| H | 1, 3, 5 | 3 | 6 | 9 | 16 | 19 | 10 | 10 |
(c) There are two critical paths of 19 days: A–C–F–G and A–D–E–G. By comparison, B–E–G takes 18 days and A–D–H takes 9. Free float: B's only successor E starts at 6, so B's FF = 6 − 5 = 1; H feeds only Finish at 19, so FF = 19 − 9 = 10.
(d) C is critical, so if it slips 2 days the project takes 21 days. B has 1 day of float, so a 3-day slip in B delays the project by 2 days (to 21), and B–E–G becomes critical.
(e) Shorten A or G, because they lie on both critical paths, which brings the project down to 18 days. Shortening C alone gains nothing, because A–D–E–G still takes 19.
P2. Least-cost crashing
Crashing means paying extra (overtime, more people) to shorten tasks. The trade is worth making while the extra direct cost per day saved is less than the indirect cost per day (overheads that run for as long as the project does). The problem. P → R and Q → R. The normal/crash days and the cost per day saved are P 6/4, $300; Q 5/3, $200; R 4/3, $500. The normal direct cost is $10,000, and the indirect cost is $550/day.
- At normal durations there are two paths: P–R = 6 + 4 = 10 days (critical) and Q–R = 5 + 4 = 9. Cost = 10,000 + 550 × 10 = $15,500. Only crashing a critical task shortens the project.
- The critical path is P–R. The cheapest option on it is P at $300/day, less than the $550/day it saves. Crash P by 1 day: paths 9/9, so 9 days; cost = 10,300 + 4,950 = $15,250.
- Now both paths are critical, so a single day must come off both: either R alone ($500) or P + Q together ($300 + $200 = $500). Both cost $500 < $550. Crash R by 1 day: paths 8/8, cost = 10,800 + 4,400 = $15,200.
- R is now at its crash limit (3 days). Crash P + Q together ($500 < $550): paths 7/7, cost = 11,300 + 3,850 = $15,150.
- P (4 days) and R (3 days) are both at their crash limits, so P–R can't get shorter: stop. The least-cost plan is 7 days at $15,150, a saving of $350 on the normal plan.
P3. Earned value
Earned value compares three numbers at a status date: what you planned to have done (PV), the budgeted value of what you actually did (EV), and what you actually spent (AC). The problem. A 10-month project has BAC $500k. At the end of month 4, PV = $200k and AC = $250k. The work packages are WP1 (budget $100k), 100% complete; WP2 ($150k), 60%; and WP3 ($250k), 10%.
EV = 100 + 0.6 × 150 + 0.1 × 250 = 100 + 90 + 25 = $215k SV = EV − PV = 215 − 200 = +$15k SPI = 215 / 200 = 1.075 → ahead of schedule CV = EV − AC = 215 − 250 = −$35k CPI = 215 / 250 = 0.86 → over budget ETC = (BAC − EV) / CPI = (500 − 215) / 0.86 = $331.4k EAC = AC + ETC = 250 + 331.4 = $581.4k (check: 500 / 0.86 = 581.4) VAC = BAC − EAC = 500 − 581.4 = −$81.4k (about 16% over) duration ≈ 10 / 1.075 = 9.3 months
P4. Risk exposure and RRL
Risk exposure (RE) is a risk's expected loss, probability × impact. Risk reduction leverage (RRL) measures how much exposure a response removes per dollar it costs. The problem. R1: the key back-end developer resigns, with P 30% and a loss of $40,000. R2: the payment-gateway API changes, with P 50% and a loss of $18,000. R3: the data migration corrupts records, with P 10% and a loss of $150,000. (a) Find each RE, the ranking and the contingency. (b) For R3 there are two options: (i) a $6,000 trial migration with reconciliation, which cuts P to 2%, or (ii) a $13,000 vendor guarantee, which caps the loss at $20,000. Which should you choose? (c) For R1, $5,000 of pairing and documentation would cut the loss to $15,000. Is it worth it?
- (a) RE1 = 0.3 × 40,000 = $12,000; RE2 = 0.5 × 18,000 = $9,000; RE3 = 0.1 × 150,000 = $15,000. So the ranking is R3, R1, R2. ΣRE = $36,000, which is a defensible contingency reserve.
- (b) Option (i) is a mitigation: REafter = 0.02 × 150,000 = $3,000, so RRL = (15,000 − 3,000)/6,000 = 2.0. Option (ii) is a transfer: REafter = 0.1 × 20,000 = $2,000, so RRL = 13,000/13,000 = 1.0, which is only break-even. Choose (i). Its residual RE of $3,000 stays on the register.
- (c) REafter = 0.3 × 15,000 = $4,500, so RRL = (12,000 − 4,500)/5,000 = 1.5 > 1, and the response is worthwhile. Note that it mitigates the impact, not the probability.
P5. Velocity forecast and burndown
Velocity is the number of story points a team gets to "Done" per sprint, averaged over recent sprints; it turns a backlog's size into a forecast. The problem. The release backlog is 260 SP, and sprints 1–3 delivered 34, 41 and 38 Done SP. (a) Forecast the delivery. (b) The date is fixed at the end of sprint 6: what follows? (c) Sprint 4 commits 38 SP over 10 days, and 26 SP remain after day 6. Interpret this.
- (a) V = (34 + 41 + 38)/3 = 113/3 = 37.7 SP/sprint. Remaining = 260 − 113 = 147, and 147/37.7 = 3.9, which rounds up to 4 more sprints (7 in total).
- (b) Three sprints × 37.7 ≈ 113 SP, so about 34 SP won't fit. Date and quality are fixed, so scope has to flex: either the Product Owner defers the lowest-priority 34 SP, or the stakeholders agree a later date (Part VI).
- (c) The ideal burn is 38/10 = 3.8 SP/day, so the ideal remaining at day 6 is 38 − 22.8 = 15.2. The actual figure is 26, which puts the team 10.8 SP behind. Raise the blockers at the Daily Scrum, swarm on the in-progress stories, and agree with the PO which low-priority item leaves, so that the Sprint Goal is protected. Never drop DoD items.
P6. NPV, ROI and payback
Money later is worth less than money now, so investment appraisal discounts each future year's flow by DF = 1/(1 + r)t before adding it up. The problem. The discount rate is r = 10%. Costs ($k) are 300 in year 0, then 30 a year in years 1–4. Benefits are 110, 140, 160 and 160 in years 1–4. The minimum acceptable ROI is 12%.
| Year | 0 | 1 | 2 | 3 | 4 |
|---|---|---|---|---|---|
| Net flow | −300 | 80 | 110 | 130 | 130 |
| Cumulative | −300 | −220 | −110 | +20 | +150 |
| DF | 1 | 0.9091 | 0.8264 | 0.7513 | 0.6830 |
| Discounted net | −300.00 | 72.73 | 90.91 | 97.67 | 88.79 |
| Cumulative discounted | −300.00 | −227.27 | −136.36 | −38.69 | +50.10 |
- Year 0: net flow −300 (the up-front cost). Year 0 is not discounted: DF = 1/(1.1)0 = 1.
- Year 1: net = 110 − 30 = 80. DF = 1/1.1 = 0.9091, so it is worth 72.73 today. Cumulative: −220 undiscounted, −227.27 discounted.
- Year 2: net = 140 − 30 = 110 × 0.8264 = 90.91. Cumulative: −110, −136.36 discounted.
- Year 3: net = 160 − 30 = 130 × 0.7513 = 97.67. The undiscounted total turns positive (+20); discounted is still −38.69.
- Year 4: net 130 × 0.6830 = 88.79. Discounted cumulative = +50.10 = the NPV, positive, so accept. Discounted costs = 300 + 27.27 + 24.79 + 22.54 + 20.49 ≈ 395.1, and discounted benefits = 100.00 + 115.70 + 120.21 + 109.28 ≈ 445.2: NPV = 445.2 − 395.1 = +$50.1k. ROI = 50.1/395.1 = 12.7%, above the 12% minimum.
- Payback is where each line crosses zero. Undiscounted: 2 full years, then 110 still to recover out of year 3's 130: 2 + 110/130 = 2.85 years. Discounted: 3 + 38.69/88.79 = 3.44 years. Discounting always pushes payback later. Undiscounted, the ROI would wrongly come out at (570 − 420)/420 = 35.7%.
P7. Quick-fire
- (a) When a team grows from 8 to 12, the channels go from 8 × 7/2 = 28 to 12 × 11/2 = 66. That is +38 (+136%) for +50% people.
- (b) 36 person-months in 9 months needs 36/9 = 4 people, if the work divides (Brooks: people and months are not interchangeable).
- (c) On WSJF (weighted shortest job first, SAFe's way of ordering work), X (cost of delay 20, size 5) scores 4.0 and Y (CoD 27, size 9) scores 3.0, so do X first.
- (d) With an estimate of $2.0M and an actual cost of $3.1M, the overrun = 1.1/2.0 = 55%.
- (e) P 60% and impact 8/10 give RE = 4.8, and on the course's 3 × 3 matrix medium likelihood × high impact comes out High.
Check yourselfIn P1, task D's duration rises from 2 to 4 days. What is the new project duration, and which paths are critical?
D now runs 4–8, so E starts at max(EF B 5, EF D 8) = 8 and runs 8–17; G starts at max(17, 15) = 17 and ends at 21 days. A–D–E–G = 4 + 4 + 9 + 4 = 21 is now the only critical path; A–C–F–G (19) has 2 days of slack. A–D–H = 4 + 4 + 3 = 11.
Check yourselfA project has EV $90k, PV $100k, AC $80k. Which statement is correct?- Behind schedule and over budget
- Behind schedule and under budget
- Ahead of schedule and over budget
- Ahead of schedule and under budget
B. SV = EV − PV = 90 − 100 = −$10k (behind; SPI 0.9). CV = EV − AC = 90 − 80 = +$10k (under budget; CPI 1.125). A student who computes CV as AC − EV gets −10 and wrongly picks A.
Check yourselfA risk has P = 20% and impact $50,000. A $4,000 response would cut P to 5%. Work out the RRL and say whether it is worthwhile.
RE before = 0.2 × 50,000 = 10,000 RE after = 0.05 × 50,000 = 2,500 RRL = (10,000 − 2,500) ÷ 4,000 = 1.875
RRL > 1, so it is worthwhile: each dollar spent removes about $1.88 of expected loss. The residual $2,500 stays on the register.
Check yourselfA backlog has 200 SP left and the team's velocity is 45 SP/sprint. How many sprints, and why not 4.4?
200 ÷ 45 = 4.44, which rounds up to 5 sprints. Sprints are fixed timeboxes, so the last 20 SP still need a whole sprint; forecasts always round up.
Check yourselfWhy does discounted payback (3.44 years) come out later than simple payback (2.85 years) in P6?
Discounting shrinks every future inflow (year 3's 130 is worth only 97.67 today), while the year-0 cost is not discounted at all. Smaller inflows take longer to repay the same outlay, so the cumulative line crosses zero later. That is also why NPV (+50.1) is far below the undiscounted total (+150).
- Learn the formula table with its traps: forward pass max, backward pass min; EV first in every variance and index; forecasts round up; year 0 is not discounted.
- Show formula → substitution → result with units → meaning, so a slip still earns method marks.
- The seven drills cover CPM with PERT estimates, crashing, earned value, RE and RRL, velocity and burndown, NPV/ROI/payback, and quick-fire channels, staffing, WSJF and overruns.
The Past Papers
Old exam papers are the best evidence of how examiners in this area think, but SWEN90016 has none of its own. The study guide uses papers from two older subjects instead. This section says what they are, how far to trust them, which topics they favoured, and where each question's model answer sits.
What they are
The past papers are transcribed library scans from two predecessor subjects (earlier subjects that covered similar ground): 433-443 Software Project Management (1998–2002), and the process-and-management Part A (plus one stakeholder question) of 433-341 Software Engineering Process and Practice (2008, 2009). No SWEN90016 paper exists. Throughout this site, questions from these papers are labelled as coming from a predecessor subject, and their model answers are the study guide's, not official.
How far to trust them
Topic frequency
The papers hold 79 questions (counting 1999 Q19 as three parts), and the chart shows how they spread over the study guide's sections, with the Part of this site that covers each.
So the old examiners returned most often to quality and reviews, scheduling calculations, people and stakeholders, SDLC choice and risk, and all of these are still core. The old papers say nothing about Agile, Scrum, SAFe and ethics, so for those use each Part's self-test questions, the tutorials and the Canvas practice exam, whose official answers sections 12.10 and 12.11 explain.
Where each old question's model answer sits
The study guide places every old question in the self-test of the section that teaches it. The table gives, for each paper, the question and the self-test question that holds its model answer, written as Part · question number in the guide's self-test (for example "II·Q4" is the guide's §2.14 self-test, question 4, in Part II).
| Paper | Question → self-test with the model answer |
|---|---|
| 433-443 1998 | Q1 I·Q1; Q2 II·Q1; Q3 VIII·Q12; Q4 V·Q1; Q5 VIII·Q16; Q6 IV·Q2; Q7 X·Q1; Q8 IX·Q14; Q9 VII·Q1; Q10 V·Q2; Q11 II·Q2; Q12 II·Q3 |
| 433-443 1999 | Q1 II·Q4; Q2 II·Q5; Q3 VIII·Q12; Q4–Q5 VIII·Q7; Q6 V·Q3; Q7 V·Q4; Q8 IV·Q6; Q9 IV·Q3; Q10 VII·Q2; Q11 VII·Q3; Q12 VII·Q4; Q13 VII·Q5 and X·Q3; Q14 VIII·Q15; Q15 IX·Q10; Q16 IX·Q11; Q17 VII·Q6; Q18 X·Q2; Q19.1 VIII·Q14; Q19.2 II·Q9; Q19.3 IV·Q7 |
| 433-443 2000 | Q1 II·Q6; Q2 VIII·Q13(b); Q3 V·Q5; Q4 IV·Q4; Q5 V·Q6; Q6 VIII·Q16; Q7 IX·Q12; Q8 VII·Q7 |
| 433-443 2001 | Q1 I·Q2; Q2 V·Q4; Q3 X·Q4; Q4 X·Q5; Q5 VII·Q8; Q6 VII·Q9; Q7 VII·Q10; Q8 IV·Q5; Q9 V·Q7; Q10 V·Q8; Q11 VIII·Q13(a); Q12 VIII·Q18; Q13 IV·Q8; Q14 IX·Q13; Q15 IX·Q14 |
| 433-443 2002 | Q1 I·Q3; Q2 V·Q9; Q3 I·Q4; Q4 VIII·Q4; Q5 VIII·Q5; Q6 VIII·Q13(a); Q7 VIII·Q17; Q8 VIII·Q10; Q9 VIII·Q4; Q10 II·Q7; Q11 VII·Q11; Q12 VIII·Q11; Q13 VIII·Q9; Q14 VIII·Q6 |
| 433-341 2008 | Q1 VIII·Q3; Q2 I·Q5; Q3 VII·Q12; Q4 VII·Q13; Q5 V·Q10 |
| 433-341 2009 | Q1 I·Q6; Q2 II·Q8; Q3 VIII·Q2; Q4 VII·Q14 |
Answer an old question as if it were in the 2026 format: give yourself one minute per mark at 2026 rates, type it in a plain text box, and apply the 2026 skeletons (section 12.3). About 15 of them, spread across the sections, make a mock exam (section 12.9).
Check yourselfTrue or false: "The old papers show that SAFe and Scrum are rarely examined, so they are low priority."
False. The old papers (1998–2009) have nothing at all on Agile, Scrum, agile planning, SAFe or the ACS Code, so they can't tell you how often those are examined now. In 2026 those topics fill half the lectures, and the official practice exam asks about release planning, Sprint Planning, the DoD, the Product Backlog and SAFe. Trust the old papers' style, not their weighting.
Check yourselfWhich topic appears in all seven old papers? (Select all that apply.)- Quality and reviews
- Risk
- Scheduling, CPM and crashing
- Configuration management
A and C. Quality and reviews (14 questions) and scheduling (13) appear in all seven papers. Risk (7) appears in 1998–2001 only, and configuration management (4) in 1998, 1999 and 2001.
- The past papers come from predecessor subjects 433-443 (1998–2002) and 433-341 (2008–09); no SWEN90016 paper exists.
- Trust their style, not their format or weighting: they lack Agile, Scrum, SAFe and the ACS Code entirely, and over-represent older topics.
- Their favourites, quality, scheduling, people, SDLC choice and risk, are still core; every old question has a model answer in a Part's self-test.
Must-Know Lists exam
Many questions, objective and written, rest on a counted list: "the five Scrum events", "the four ACS values". Get the count wrong, or slip in an item from a neighbouring list, and the marks go. These are the lists to be able to recite cold, with the right count. Each row gives the items in brief; the Part named in the tab teaches them in full.
| List | Items in brief | Part |
|---|---|---|
| Project characteristics (6) | change; temporary; cross-functional; the unknown; unique; varies in size | I |
| Triple constraint; process groups (5) | time, resources (cost), scope, quality inside; initiating, planning, executing, monitoring and controlling, closing | I |
| CHAOS outcomes (3); top factors | successful, challenged, failed; executive sponsorship, emotional maturity, user involvement, optimisation (15% each, non-technical) | I |
| Business case contents (9) | executive summary, reasons, options, benefits, dis-benefits, timescale, costs, investment appraisal, major risks | I |
| Appraisal techniques (4); charter sections | ROI, NPV, payback, ROM; purpose, objectives (scope, deliverables), overview, schedule, personnel and stakeholders, risk management, approval | I |
| Royce's five fixes | program design first; document the design; do it twice; plan, control and monitor testing; involve the customer | II |
| Spiral quadrants (4); Boehm's difficulties (3) | objectives and constraints → evaluate alternatives, resolve risks → develop and verify → plan next; contract fit, needs risk expertise, needs elaboration | II |
| Formal / agile / hybrid (T02) | formal: customer knows, stable requirements, mature tech; agile: customer gives time, requirements emerge, change welcome; hybrid: client's prescriptive model | II |
| List | Items in brief | Part |
|---|---|---|
| Manifesto values (4) | individuals and interactions; working software; customer collaboration; responding to change (each over its right-hand item) | III |
| Agile principles (12) | early continuous delivery; welcome change; deliver frequently; business and developers daily; motivated individuals; face-to-face; working software = progress; sustainable pace; technical excellence; simplicity; self-organising teams; reflect and adjust | III |
| Agile mindset pillars (4) | respect; sustainable flow; innovation; relentless improvement | III |
| Agile assumptions (8; slides show 5) | one stakeholder role; small co-located team; user available; non-critical; quick prioritised increments; little documentation; early release over verification; no major refactoring, developers maintain | III |
| XP values (5); Kanban fundamentals (5) | communication, simplicity, feedback, courage, respect; visualise, limit WIP, manage flow, explicit policies, improve | III |
| Scrum pillars (3); values (5) | transparency, inspection, adaptation; commitment, focus, openness, respect, courage | III |
| Scrum accountabilities (3) | Product Owner (value, backlog); Scrum Master (effectiveness, servant leader); Developers (Sprint Backlog, DoD) | III |
| Scrum events (5), 1-month timeboxes | Sprint ≤ 1 month; Planning 8 h; Daily Scrum 15 min; Review 4 h; Retrospective 3 h | III |
| Scrum artefacts (3) → commitments | Product Backlog → Product Goal; Sprint Backlog → Sprint Goal; Increment → Definition of Done | III |
| List | Items in brief | Part |
|---|---|---|
| Kinds of risk (3); process (5) | project, product, business; plan, identify, analyse and assess, respond, monitor and control | IV |
| Risk identification (6) | pondering; interviews; brainstorming; checklists; Delphi; SWOT | IV |
| Risk responses | threats: accept, avoid, mitigate, transfer; opportunities: exploit, enhance, share, accept | IV |
| Register fields (5); monitoring tools (3) | ID, trigger, owner, response, resources; audits, reviews, status meetings | IV |
| Why document in agile (4); how (3) | organisational memory; external groups; audit and compliance; complex ideas; JBGE (just barely good enough), just in time, living | V |
| Stakeholder analysis (5); engagement levels (5) | identify, understand interests, assess influence, prioritise, manage relationships; unaware, resistant, neutral, supportive, leading | V |
| Power–interest grid (4) | manage closely; keep satisfied; keep informed; monitor | V |
| Team structures (4); teamicide (7) | autocracy, anarchy, democratic, collaborative; defensive management, bureaucracy, separation, fragmented time, quality-reduced product, phony deadlines, clique control | V |
| Communication model; plan (11) | source, transmitter, channel, receiver, destination, noise, feedback; what, channel, when, who, needs, resources, confidentiality, flow, constraints, templates, escalation | V |
| Conflict modes (5) | forcing, accommodating, avoiding, compromising, collaborating (preferred) | V |
| List | Items in brief | Part |
|---|---|---|
| Backlog steps (5); 3 C's | user stories, acceptance criteria, MoSCoW, story points, DoD; card, conversation, confirmation | VI |
| INVEST | independent, negotiable, valuable, estimable, small, testable | VI |
| MoSCoW | must, should, could, won't (this time) | VI |
| Why story points (4) | relative is easier; hours ignore overheads; velocity hard to weaponise; value vs effort | VI |
| Sprint Planning topics (3); DoD levels (3) | why (Sprint Goal), what (PBIs), how (tasks ≤ 1 day); PBI, sprint, release | VI |
| Planning pitfalls (7) | overcommitting; no release plan; no continuous testing; unclear test procedures; weak sprint planning; late technology decisions; unclear roles | VI |
| List | Items in brief | Part |
|---|---|---|
| Cost of quality (4) | prevention, appraisal (conformance); internal, external failure (nonconformance) | VII |
| QM processes (3); test levels (4) | plan, assure (process), control (product); unit, integration, system, acceptance | VII |
| SQA plan sections (6) | product overview; product plan; quality goals; process; standards; risks | VII |
| Reviews: kinds; formal types; roles | technical, management, business; walkthrough, inspection, audit; moderator, author, reader, recorder, inspectors | VII |
| CMM levels (5) | initial, repeatable, defined, managed, optimising | VII |
| McCall (11 factors, 3 groups) | operation: correctness, reliability, efficiency, integrity, usability; revision: maintainability, flexibility, testability; transition: portability, reusability, interoperability | VII |
| ISO/IEC 25010:2023 (9) | functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility, safety | VII |
| List | Items in brief | Part |
|---|---|---|
| Schedule steps (5); WBS rules (5) | WBS, dependencies, estimates, resources, schedule; 100%, deliverable-oriented, mutually exclusive, work packages, numbered | VIII |
| Dependencies (4); EV terms | FS, SS, FF, SF; PV (BCWS), EV (BCWP), AC (ACWP), BAC | VIII |
| List | Items in brief | Part |
|---|---|---|
| ACS values (4); ethics steps (7) | honesty, trustworthiness, respect for others, respect for the profession; facts, stakeholders, issues, clauses, options, decision, act and prevent | IX |
| CM activities (5); IEEE 828 (4) | identification, version control, change control, auditing, status reporting; identify, control, status accounting, audit | X |
| CI types (3); version, variant, release | basic, aggregate, derived; new function, same function on another platform, delivered externally | X |
| Change control (3); CCB outcomes | initiate, evaluate, make; approve, approve with conditions, defer or reject | X |
| Essential SAFe areas (7) | PI Planning, ART, roles, Scrum of Scrums, Program Backlog, System Demo, Inspect & Adapt | XI |
| SAFe roles (7) | RTE, Product Management, System Architect, Business Owners; PO, Scrum Master/Team Coach, Agile Team | XI |
| PI Planning outputs; ROAM | PI objectives, program board, ROAMed risks, iteration plans, confidence vote; resolved, owned, accepted, mitigated | XI |
| Scrum → SAFe events | Planning → PI Planning; Daily Scrum → Scrum of Scrums; Review → System Demo; Retrospective → Inspect & Adapt | XI |
A few abbreviations from the tables: ROM rough order of magnitude; WIP work in progress; PBI Product Backlog item; SQA software quality assurance; CMM Capability Maturity Model; FS, SS, FF, SF finish-to-start, start-to-start, finish-to-finish, start-to-finish; BCWS/BCWP/ACWP the older names for PV, EV and AC (budgeted cost of work scheduled, budgeted cost of work performed, actual cost of work performed); CI configuration item; CCB change control board; PI Program Increment; ART Agile Release Train; RTE Release Train Engineer; ROAM the four ways a PI Planning risk is dealt with.
"Contingency" is not one of the four threat responses (accept, avoid, mitigate, transfer). "Backlog refinement" is not one of the five Scrum events. SAFe's System Demo is not the Scrum Sprint Review, though it is its scaled counterpart. A list question checks the count and the boundary of the list.
Check yourselfWhich of these are Scrum artefacts, as opposed to commitments? (Select all that apply.)- Product Backlog
- Sprint Goal
- Increment
- Definition of Done
- Sprint Backlog
A, C and E. The three artefacts are the Product Backlog, the Sprint Backlog and the Increment. The Sprint Goal (B) and the Definition of Done (D) are commitments, attached to the Sprint Backlog and the Increment respectively; the third commitment is the Product Goal.
Check yourselfName the four ACS values and the five CM activities, without looking.
ACS values (4): honesty, trustworthiness, respect for others, respect for the profession. CM activities (5): identification, version control, change control, (configuration) auditing, status reporting.
Check yourselfWhich of these are among the six risk-identification techniques? (Select all that apply.)- Delphi
- Risk exposure
- SWOT
- Brainstorming
- Transfer
A, C and D. The six are pondering, interviews, brainstorming, checklists, Delphi and SWOT. Risk exposure (B) is an analysis measure, and transfer (E) is a response: both belong to other lists.
- Learn every list with its count; a wrong count or an item from a neighbouring list loses marks.
- Scrum is 3–5–3–5–3: pillars, values, accountabilities, events, artefacts (each artefact with its commitment).
- Put the lists on your notes sheets grouped by topic, and recite them cold in the final fortnight.
The Project in the Exam
The exam covers "the project" (W01a), meaning your A2 team project, run with Agile and Scrum. A question such as "Describe how your team did X and evaluate it against Scrum" can only be answered from your own experience, so it pays to prepare that experience as evidence. Assignment 2 ran until 23 October 2026, and AI help on assessments isn't allowed, so this site says nothing about the A2 brief or its deliverables. Use this section only after your team has submitted.
What to be ready to discuss
Be ready to discuss each of these, with a concrete example from your own team.
Roles
Who acted as Product Owner and Scrum Master, and how decisions were made.Sprint planning
Your Sprint Goals, how you selected items, and how you broke them into tasks.Estimation
The technique you used, your estimates against the actuals, and the lessons.Velocity and burndown
What your charts showed, and why.DoD and acceptance criteria
Their contents and how they changed, and any "done but not Done" work.Daily stand-ups
The format, and the impediments raised and removed.Reviews and retrospectives
The feedback you received, and one improvement and whether it worked.Risks and issues
The ones you actually hit, and your responses.Communication and conflict
Your channels and norms, and one disagreement and how it was resolved.Git as configuration management
Branches, pull-request reviews, merge conflicts, and tags as baselines.Quality practices
Your reviews and testing, and what the DoD enforced.Documentation and tailoring
What you documented and why, and where you were hybrid rather than pure Scrum."Done but not Done" is work the team called finished that didn't meet the Definition of Done, such as a feature coded but never tested. A hybrid process mixes a formal model's practices into an agile one, for example a client-required design document inside Scrum.
A reflective answer in four steps
What we did: "In sprint [n] we committed to [x] story points, including one story, [story], estimated at [y] points." What happened: "We finished [z] points; the burndown stayed flat for [k] days because that story wasn't Done until the last day." Why: "The story broke INVEST's small: it couldn't be finished inside a few days, so no progress showed until it was all done." What we'd change: "Split stories over [y] points at refinement, so each fits a few days and the burndown shows real progress."
Fill the brackets from your own team's records; invented details are easy for a marker to spot.
Check yourself"Our retrospectives went well and everyone enjoyed them." What is missing from this reflective answer?
Almost everything after step 1. It needs evidence (what came out of the retrospectives: an action, a changed practice, a number), a why in course terms, and a specific change with its expected effect. Better still, pick a retrospective action that didn't work and explain why: an honest analysis of a failure beats a described success.
- The exam can ask how your team ran Scrum; prepare twelve areas, from roles and estimation to Git and documentation, each with a concrete example.
- Answer reflectively in four steps: what we did → what happened (evidence) → why (course terms) → what we'd change (practice + effect).
- Honest analysis of failure scores better than a polished success story; use this section only after A2 is submitted.
The Final-Fortnight Plan
Revision without a plan drifts towards the topics you already like. This plan spreads the whole course over the last four weeks before the exam, then switches from learning to rehearsal. It assumes about 2–3 hours a day; shift days around your other exams, which start on 2 November.
Two words in it need defining. On a section day, read the Part, do its self-test questions without looking, mark them, and log every miss in an error log, a running list of what you got wrong and why. "Timed" means typed in a plain text box against the clock, as in the exam. The subject's consultation sessions run in SWOTVAC and the week before the exam (details on Canvas), so take your error log's open questions to them.
| Day | The plan in full |
|---|---|
| Mon 26 Oct | Read sections 12.1–12.3 (the format is now confirmed), set up LockDown Browser using the university's student guide, and start the error log. |
| Tue 27 Oct | Study Part I and do its self-test, then drill P6. |
| Wed 28 Oct | Study Part II and do its self-test, then write the 12.4 steps from memory. |
| Thu 29 Oct | Study Part III and do its self-test, then learn the Scrum rows of 12.7. |
| Fri 30 Oct | Study Part VI and do its self-test, then drill P5. |
| Sat 31 Oct | Study Part IV and do its self-test, then drill P4. |
| Sun 1 Nov | Study Part V and do its self-test, then drill P7. |
| Mon 2 Nov | Study the first half of Part VIII (the guide's §8.1–§8.9: WBS to crashing) and do self-test Q1–Q6, then drill P1 and P2. |
| Tue 3 Nov | Study the second half of Part VIII (§8.10–§8.15: earned value onwards) and do self-test Q7–Q18, then drill P3. |
| Wed 4 Nov | Study Part VII and do its self-test. |
| Thu 5 Nov | Study Part IX and do its self-test, then answer one ethics scenario, timed (15 min). |
| Fri 6 Nov | Study Part X and do its self-test. |
| Sat 7 Nov | Study Part XI and do its self-test, then redo the T10 NovaSuite activities without looking. |
| Sun 8 Nov | Work through section 12.4, then write a timed (25 min) Medic SDLC answer on the Part II (spiral) or Part III (adapted Scrum) facts. |
| Mon 9 Nov | Recite every list in 12.7 cold, re-learn the misses, and start drafting your two double-sided A4 notes sheets (12.1). |
| Tue 10 Nov | Write the 12.5 formula sheet from memory, and redo P1–P7 without notes. |
| Wed 11 Nov | Mock 1, timed like the real exam (15 minutes' reading, then 2 h): the Canvas practice exam in its LockDown Browser version if you haven't yet done it, otherwise about 15 old questions from 12.6 spread across the sections. Mark it against the staff's official Practice Exam Guide, using 12.10–12.11 to see why each answer is right and which Part to revisit. Judge your written answers on their structure and their use of the scenario rather than on matching the staff's wording, and don't rote-learn the answers; then redo the PERT and earned-value questions with changed numbers. |
| Thu 12 Nov | Use the error log to pick the two weakest sections, and re-study them. |
| Fri 13 Nov | Do a Medic sweep: every Medic application (one per Part), the T01 drivers and the T02 SDLC arguments. |
| Sat 14 Nov | For the project, write five short reflections from your own notes (12.8). Finalise and print your notes sheets. |
| Sun 15 Nov | Mock 2, timed at 2 h: the self-test questions you missed, plus one new case answer. |
| Mon 16 Nov | Review mock 2, redo the calculations you missed, and re-read the 12.3 table. |
| Tue 17 Nov | Keep it light. Go over the formulas and lists once; check your laptop, charger, LockDown Browser and Canvas login; pack your photo ID and printed notes sheets; and sleep. |
| Wed 18 Nov | Exam, 12:30–2:45 pm at the Royal Exhibition Building East (15 minutes' reading, then 2 hours). Skim your notes sheets in the morning, and arrive early. |
Check yourselfYou sit Mock 1 and your written answer on the stakeholder question names different roles from the staff's answer. Is that a problem?
Not in itself. The staff label their scenario answers as examples with "variations accepted", and the plan says to judge your answers on structure and use of the scenario, not on matching the staff's wording. What matters is whether each placement is justified with evidence from the scenario. Rote-learning the staff's roles would, in the staff's own words, likely attract low marks.
- Weeks 1–2: a Part a day with its self-test and a drill, logging every miss in an error log.
- Weeks 3–4: lists, formulas, notes sheets, two timed mocks marked against the official guide by structure, not wording, and the weakest sections again.
- The day before is light: check the laptop, pack ID and notes, and sleep.
The Official Practice Exam: MCQs and MRQs exam
On 29 October the coordinator posted a Practice Exam Guide on Canvas (Modules > Practice Exam), introduced as an example of how to address the questions. It gives the staff's answer to every question on the practice exam: seventeen multiple-choice and multiple-response items, a PERT question, an earned-value question, and three scenario questions on ethics, stakeholders and agile reasoning. These answers are official: they are the subject staff's own. This section and the next work through them, explaining why each answer is right and pointing to the Part that teaches the idea, because what carries over to a final with different questions is the reasoning, not the answers.
The practice exam's question text isn't among the files the study guide was built from, so where the wording of a question matters, the explanation infers it from the answer and says so. In three places the staff's own working contains a slip: the earned-value fractions, the name of a dependency type, and the polarity of two Scrum answers. In each case the correct version is given beside the staff's, so that you take the right formula or definition into the exam rather than the typo.
What the staff say about marking
- Definition-style answers attract low marks. A written answer that explains what a concept is, without using it on the question's facts, scores poorly however accurate it is.
- Rote-learning the answers in the guide is likely to attract low marks. The staff want you to show understanding by applying the concepts to different scenarios, questions and contexts, and to give justifications that bear directly on the question asked.
- When a question tells you to base your response on the scenario, do exactly that, and feel free to quote the relevant parts of it; a few quoted words such as "one of many initiatives" are often the strongest evidence you can give.
- The topics in the real exam may differ from the practice exam. The Ed FAQ adds that the final is similar in difficulty, but that the topics, and what you are asked to do with them, can change.
Taken together, these warnings explain the shape of every model answer below. Each one names a concept, ties it to a specific fact in the scenario, and says why that fact supports the conclusion (the justification). That chain is what earns the marks, and it is the thing to practise. The scenario answers are also labelled as examples with "variations accepted", so a different stakeholder, issue or acceptance criterion scores just as well if you justify it from the scenario. Since the Ed FAQ confirms that every written answer is partially marked, a well-reasoned answer that differs from the staff's is not wasted.
The seventeen objective questions, by topic
Several staff answers list two, three or even four options, which marks those questions as multiple-response, so keep the scoring rule in mind: each wrong tick cancels a right one. Q16 has four correct options, one more than the "two or three" the revision lecture gave as typical, so treat that figure as a guide rather than a cap and judge every option on its own merits. The answers are grouped by topic rather than in question order, so that each group sends you back to one Part.
Agile release and sprint planning (Q1, Q2, Q8, Q9, Q15)
Q1's answer is that in fixed-date release planning, scope is flexible. The staff point back to the Week 5 lecture: each sprint has a fixed length, usually two to four weeks, and work that isn't finished moves to the next sprint, so when the release date is fixed it is the amount of work that adjusts. In numbers, the team can deliver roughly velocity × the number of sprints left before the date, and the Product Owner fills that capacity from the top of the ordered backlog, deferring whatever doesn't fit. This is the "date and quality fixed, scope variable" rule and the "timebox fixed, scope flexes" rule of Part VI.
Q2 is the mirror image, fixed-scope release planning, and here the staff's wording is garbled (the transcript marks it [sic]). The idea it reaches for is that you total the story points of the scope you must deliver, the Must-haves, and divide by velocity to get the number of sprints, so the scope determines the length of the release. Read the staff's "length of the sprint" as the length of the release: a sprint is a fixed timebox and never stretches to fit the scope, and the arithmetic is T = ΣSP ÷ V.
Q8's two answers are that agile planning is iterative and is revisited in every sprint, and that it should involve the whole team: the progressive planning and the whole-team Sprint Planning of Part VI. Q9's answer, "before the development work of the sprint begins", fits a question about when Sprint Planning happens (an inference from the answer): it opens the Sprint, so the Sprint Goal and Sprint Backlog exist before anyone starts building. Q15's answer, the Sprint Backlog and the Sprint Goal, fits a question about what Sprint Planning creates or updates. The staff add a useful map of where the other items usually change.
Quality, user stories and the Definition of Done (Q3, Q7, Q16)
Q3's answer is Acceptance Test-Driven Development (ATDD), in which the stakeholders and the team agree the acceptance criteria, and write acceptance tests from them, before any code exists (Part VII). Its neighbours are easy to confuse. TDD (test-driven development) works at the level of units: a developer writes a failing unit test, then the code to pass it. BDD (behaviour-driven development) adds a shared Given–When–Then notation tied to business goals. So look for clue words such as "acceptance criteria first" or "stakeholders and team agree the tests".
Q7's two correct options are both well-formed user stories. A user story is a short requirement written from a user's point of view, in the template "As a [role], I want [goal], so that [benefit]".
"As a chef, I want to see the list of items in the current orders sorted by time, so that I can prioritise my cooking team"
"As a customer, I want to be able to view the total price of all items I have ordered, so that I know how much I have to pay"
Each names a real user role, a goal that user can act on and the benefit it brings, and each is small enough to build and test, so it fits both the template and INVEST (independent, negotiable, valuable, estimable, small, testable; Part VI). When you judge story options, rule out any that describe a technical task instead of a user's need, that lack the "so that" benefit, or that are too big for a sprint.
Q16's four correct statements are all about the Definition of Done (DoD): it can change over time as the team improves its processes, it determines when a PBI is "done", it keeps work to one standard across all teams on the same product, and it applies to every PBI selected for the Sprint. Each matches Part VI. The DoD is not static, it is the exit checklist for a Product Backlog item (PBI), teams on one product share one DoD, and it is universal rather than story-specific, which is exactly what separates it from acceptance criteria (which belong to one story).
Scheduling dependencies (Q4): a staff slip
The staff answer reads "In a Start-to-Finish dependency, the predecessor must finish before the successor can start", and the transcript marks it [sic]. That sentence is in fact the W07 slides' definition of Finish-to-Start, almost word for word. The slides define Start-to-Finish the other way round: the predecessor must start before the successor can finish, as when deploying the new version must start before the final regression tests can finish. Most likely the staff typed the wrong name when copying out the correct option, but either way, learn the slides' pairing.
An option that pairs "Finish-to-Start" with "finish before start" is true, and one that pairs "Start-to-Finish" with that wording is false. Part VIII gives all four types (FS, SS, FF, SF) exactly as the slides do.
Risk (Q5, Q17)
Q5's three correct statements are that risks can be analysed both qualitatively and quantitatively, through the risk matrix and through RE = P × I; that brainstorming is a technique for identifying risks, one of the six; and that a risk with a probability of 1 is not a risk, because an event that is certain to happen is an issue (Part IV).
Q17's three are about risk in Agile. Risk is handled effectively by showcasing features sooner than formal models do, it is handled within the iterative sprints throughout the lifecycle rather than in a separate phase, and daily stand-ups expose risks sooner in the sprint. All three come from Part IV, where each part of Scrum has a role in risk: Sprint Reviews put working software in front of stakeholders early, short sprints cap the amount of work at risk, and the Daily Scrum surfaces impediments just in time.
Configuration management (Q6)
The three correct options are identifying the project artefacts to place under configuration management (CM), branch management, and release management. They correspond to configuration identification, version control with its branches, and release management from Sommerville's framing of CM, which T09 uses (Part X).
Scrum statements that are false (Q12, Q13): check the polarity
The two staff answers here are both false as statements about Scrum:
"The increment must be in a usable state only if the Product Owner chooses to release it."
The Increment must be usable whether or not the PO releases it, because its commitment is the Definition of Done.
"The items in the Product Backlog should remain the same throughout the project."
The Product Backlog is "emergent", refined continuously as the team and the stakeholders learn, so it is expected to change.
Without the question text this can't be certain, but the most likely reading is that these questions asked which statement is not true, and the staff listed the false option as the answer. The lesson for the final is to check the stem's polarity before you choose, because under a "which is true" stem these two would be exactly the wrong answers.
Process models and SAFe (Q10, Q11, Q14)
Q14's answer is the Spiral model, which fits a question describing a risk-driven process whose loops tackle the highest remaining risks first, often by prototyping (Part II). Q10's answer, Essential SAFe, fits a question about the smallest SAFe configuration, the building block of the others, organised around a single Agile Release Train (Part XI). Q11's answer, the Program Backlog, fits a question about where the ART's upcoming work lives: it is the single source of truth owned by Product Management, and it holds Features rather than stories. (Each "fits a question about" is inferred from the answer, since the question text isn't available.)
Check yourselfA release date is fixed 4 sprints away, the team's velocity is 30 SP, and the ordered backlog holds 150 SP. What happens, and who decides?- Sprints are lengthened so that all 150 SP fit
- About 120 SP are planned and the Product Owner defers the lowest-ordered 30 SP
- The Developers choose which 30 SP to drop
- The date moves automatically to fit the scope
B. Fixed date means scope flexes (Q1): capacity ≈ 30 × 4 = 120 SP, filled from the top of the ordered backlog, and the Product Owner, who owns the backlog's order, decides what is deferred. A is wrong because a sprint is a fixed timebox; D describes fixed-scope planning, not fixed-date.
Check yourselfWhich statements about the Definition of Done are true? (Select all that apply.)- It differs for each user story.
- It can change as the team improves its process.
- All teams working on one product share it.
- It is fixed at the start of the project.
- It applies to every PBI selected for the Sprint.
B, C and E, three of the four true statements in the staff's Q16 answer. A describes acceptance criteria, which are story-specific; D is false because the DoD can change over time (usually at the Retrospective).
Check yourself"Which of these is NOT true of Scrum?" Option C reads: "The Product Backlog is refined continuously as the team learns." Should you pick C?
No. C is a true statement (the backlog is emergent), so under a "NOT true" stem it is the wrong choice. This is the polarity trap behind Q12 and Q13: decide whether each option is true, then read the stem again before you choose.
Check yourselfA question describes "a test approach where the customer and team write the acceptance tests together before development starts". Which is it?- TDD
- ATDD
- Unit testing
- Regression testing
B, ATDD (the answer to Q3). The clue words are "acceptance tests" and "customer and team together, before development". TDD works at the unit level and is written by the developer.
Check yourselfWhich pairing is correct?- Start-to-Finish: the predecessor must finish before the successor can start
- Finish-to-Start: the predecessor must finish before the successor can start
- Finish-to-Finish: the predecessor must start before the successor can finish
- Start-to-Start: the predecessor must finish before the successor can finish
B. The first word is what the predecessor must do, the second the part of the successor that waits. A is the staff's Q4 slip; C and D mix up the pairings (FF is finish before finish, SS start before start).
- The Practice Exam Guide's answers are official; the staff warn that rote-learning them is likely to attract low marks, and that the final's topics may differ.
- Fixed date → scope flexes; fixed scope → ΣSP ÷ V sets the release length; Sprint Planning makes the Sprint Backlog and Sprint Goal; the DoD is shared, universal and can change (Q16 had four correct options).
- Three staff slips to correct: Q4 is the FS definition (SF is start-before-finish); Q12 and Q13 are false statements, so check every stem's polarity.
The Official Practice Exam: Written Questions exam
The practice exam's written half has five questions: a PERT network, an earned-value calculation, and three scenarios on ethics, stakeholders and agile reasoning. The answers below are the staff's official answers from the Practice Exam Guide, explained. Remember the staff's warning: rote-learning these answers is likely to attract low marks. Learn the method each one shows, then practise it on different numbers and different scenarios.
The PERT question: critical path, duration and merge activities
The practice exam gave a table of activities with their durations and predecessors and asked for three things: the critical path, the project's duration, and its merge activities. A merge activity is one with two or more immediate predecessors, a point where paths join; its opposite, a burst activity, has two or more immediate successors (Part VIII). Canvas can't accept a drawing, so you don't submit the network, but the staff recommend drawing it on the rough paper the invigilators provide, and that is the surest way to avoid mistakes.
(i) The critical path is A → B → D → G → H. (ii) The duration is 4 + 6 + 7 + 9 + 7 = 33 days. (iii) The merge activities are D (predecessors B and C), E (predecessors B and C) and H (predecessors F and G).
The full activity table isn't available locally, but the answers fix enough of the network to draw its core. The diagram shows every link the answers imply. The predecessors of C and F, the successors of E, and the durations of C, E and F aren't given, so they are left out rather than guessed.
- Draw the network from the predecessor column: one node per activity, an arrow from each predecessor, and Start and Finish nodes. Here only the links the staff's answers imply are drawn; C's and F's predecessors, E's successors and three durations are unknown.
- Forward pass along the critical activities: ES = the largest EF among the predecessors, EF = ES + D. A 0–4, B 4–10, D 10–17, G 17–26, H 26–33. (D's ES also depends on C, and H's on F; the staff's answer implies those finish no later.)
- The critical path is A → B → D → G → H, and the duration is its length, the largest EF: 4 + 6 + 7 + 9 + 7 = 33 days. Because all five activities are critical, their late times equal their early times. On a small network, listing every path and adding its durations finds the same answer.
- Merge activities have two or more immediate predecessors: D (B, C), E (B, C) and H (F, G). B and C are also burst activities, because each feeds both D and E.
The method, so that it carries over to new numbers. On a small network the quickest way to the critical path is to list every path from Start to Finish and add up its durations; the longest is critical, and there may be more than one. On a larger network, run the forward pass and then the backward pass (LF is the smallest LS among the successors, and LS = LF − D), and the critical activities are the ones with zero total float. Finally, read down the predecessor column for every activity with two or more immediate predecessors to find the merges.
A strong answer adds a sentence of meaning to the bare list. At each merge activity the forward pass takes the latest of the incoming finishes, so D, E and H are where a slip on a feeding path, such as one through C or F, would push into the schedule once its float runs out, and they are the activities to watch. To type a network into the answer box, write one line per node, for example "D (7 d): after B, C; ES 10, EF 17; critical".
The earned value question
The question gave EV = $145,000, AC = $140,000, PV = $150,000, BAC = $500,000 and an original duration of 24 months, and asked for (A) the variances and indices, (B) whether the project is over or under budget and ahead of or behind schedule, (C) the estimate at completion, and (D) a revised time estimate. The table sets out the correct working (Part VIII).
| Quantity | Formula | Working | Result |
|---|---|---|---|
| CV | EV − AC | 145,000 − 140,000 | +$5,000 |
| SV | EV − PV | 145,000 − 150,000 | −$5,000 |
| CPI | EV ÷ AC | 145,000 ÷ 140,000 | 1.036 |
| SPI | EV ÷ PV | 145,000 ÷ 150,000 | 0.967 |
| EAC | AC + (BAC − EV) ÷ CPI | 140,000 + 355,000 ÷ 1.036 | $482,664 |
| Time | original duration ÷ SPI | 24 ÷ 0.967 | 24.8 months |
CPI = EV / AV = 140000/145000 = 1.036
SPI = EV / PV = 150000/145000 = 0.967
The formulas named are right, apart from "AV" where it means AC, but the fractions are upside down: 140,000/145,000 is 0.966 and 150,000/145,000 is 1.034, the reverse of the answers given.
CPI = EV / AC = 145000/140000 = 1.036
SPI = EV / PV = 145000/150000 = 0.967
The staff's final figures of 1.036 and 0.967 are correct, and they come from these fractions. EV comes first in every variance and every index, which is why a positive variance or an index above 1 is always good news.
Part B: what the numbers mean. CV is positive and CPI is above 1, so the project is under budget by $5,000, earning about $1.04 of planned work for every dollar spent. SV is negative and SPI is below 1, so it is behind schedule: $5,000 worth of planned work hasn't been done yet. That puts the project in the "under budget, behind schedule" cell, where the usual explanation is that work isn't getting done, because the team is short-staffed or blocked, rather than that it is unusually efficient. Saying so earns more than the bare verdict "under budget and behind schedule".
Part C: the estimate at completion. The forecast assumes the remaining work continues at the current cost efficiency. The work still to do is BAC − EV = $355,000 at its budgeted value; at a CPI of 1.036 it will cost 355,000 ÷ 1.036 = $342,664, and adding the $140,000 already spent gives the staff's EAC of $482,664.09. If you keep the CPI unrounded (1.0357), the EAC comes out at $482,758.62, which also equals BAC ÷ CPI. The difference of about $95 comes only from rounding the CPI before dividing, so either figure should be fine as long as your working shows where it came from; rounding only at the end gives the second. If a part asks for the variance at completion, VAC = BAC − EAC ≈ +$17,000, so the project is forecast to finish about $17,000 under budget.
Part D: the time estimate. Dividing the original duration by SPI gives 24 ÷ 0.967 = 24.81 months, about 0.81 of a month late. The staff convert that at 30 days a month to about 24.3 days, or roughly three and a half weeks. Like the EAC, this assumes the current schedule efficiency continues, and it is a rough forecast, not a re-planned schedule.
Practise it with new numbersEV = $140,000, AC = $150,000, PV = $145,000, BAC = $500,000, 24 months. Answer parts A–D before opening.
CV = 140,000 − 150,000 = −$10,000 CPI = 140,000 ÷ 150,000 = 0.933 → over budget SV = 140,000 − 145,000 = −$5,000 SPI = 140,000 ÷ 145,000 = 0.966 → behind schedule EAC = 150,000 + 360,000 ÷ 0.9333 = $535,714 (about $35,700 over budget) time ≈ 24 ÷ 0.9655 ≈ 24.9 months
Over budget and behind schedule is the worst cell of the matrix (badge N), and it calls for urgent re-planning.
The ethics question: SecureTrack
The scenario concerned SecureTrack, a company supplying facial-recognition technology. The staff's example answer, with variations accepted, sets each issue out in three parts: a name for the issue, a description tied to the scenario, and the relevant ACS values, cited by value and clause letter. The staff write the clauses as, for example, "Trustworthiness (d)", which is clause 2.2(d) in the study guide's numbering of the 2023 ACS Code (Part IX); either form is fine as long as the value and the letter match the 2023 Code.
In more detail: the first issue is a violation of privacy and public trust. The system collected, stored and analysed people's biometric data without their knowledge or consent, and its matches led to wrongful detentions. The staff cite Trustworthiness (d), respecting the privacy, confidentiality and integrity of personal data, and Trustworthiness (a), being accountable for the consequences of one's work. The second is dishonesty in representing the company's capabilities: SecureTrack exaggerated its expertise and its security when bidding for the work, and a later breach exposed the gap. This falls under Honesty (a), being truthful and transparent, and Honesty (b), not misrepresenting capabilities and not omitting limitations or risks. The third is harmful predictive profiling and discrimination, because the system built "generalised suspect profiles". The staff cite Respect for Others, starting from its overarching duty to minimise harm and the mitigation that clause (a) requires, together with (c) on unfair discrimination and (d) on inclusivity and fairness. The fourth is a failure to ensure accuracy and reliability: the system made frequent false identifications and was released without adequate testing, which breaches Trustworthiness (g), being competent and diligent, and (h), building systems that are robust, secure and user-friendly.
"Privacy: the ACS Code says to respect privacy."
A definition with no scenario evidence and no consequence: exactly what the staff say scores low.
Violation of privacy and public trust. SecureTrack's system collected, stored and analysed people's facial biometrics without their knowledge or consent, and its matches led to wrongful detentions. This breaches ACS Trustworthiness 2.2(d), which requires professionals to respect the privacy, confidentiality and integrity of personal information: biometric data is about as sensitive as personal data gets, and the people affected never agreed to its use. It also breaches 2.2(a), accountability, because SecureTrack has to own the harm its system caused, including the detentions, rather than leave it to the people wrongly detained.
You could also strengthen several of the staff's points with clauses they didn't cite: 2.3.1(f), identifying and mitigating risks to others, fits the release without adequate testing, and 2.2(e)–(f), on communicating capability honestly and not taking on work beyond your skills, fits the inflated bid. If the question goes on to ask what a professional should do, continue with the last steps of Part IX's seven-step method: the options, a justified decision, and escalation. The consent failure parallels Facebook and Cambridge Analytica (Part IX), which is a useful comparison if a question invites one.
The stakeholder question: Guardian Assurance Solutions
The scenario was an insurer, Guardian Assurance Solutions (GAS), modernising its IT with the help of a consulting firm, Tech Innovate Solutions. Part A asked for a stakeholder role in each quadrant of the power–interest grid, which places each stakeholder by how much they can affect the project (power) and how much they care about it (interest), and so says how to engage them (Part V).
Notice that the CEO lands in "keep satisfied" here, although Part V's generic grid lists the CEO as a typical "manage closely" stakeholder. The scenario evidence decides it: the project is "one of many initiatives", and the CEO is not involved in "day-to-day operations". This is exactly why the staff warn against generic answers, since the textbook placement would have been wrong for this case.
Part B asked for the justifications, and the staff's model shows the pattern to follow: give one piece of evidence for the level of power, one for the level of interest, and quote the scenario where you can.
| Role | Power, because… | Interest, because… |
|---|---|---|
| CEO of GAS | High: can terminate or continue the project depending on how well it fits the company's strategy | Low: the project is "one of many initiatives", and the CEO stays out of "day-to-day operations" |
| Tech Innovate's PM | High: oversees "daily execution", decides on budget, resources and direction, resolves issues across departments | High: the project's success affects the consulting firm's reputation and is the PM's own professional responsibility |
| GAS IT Support Team (reading 1) | Low: gives technical assistance only, makes no strategic decisions | Low: supports many projects besides this one |
| GAS IT Support Team (reading 2) | Low: no authority | High: will own support and maintenance after handover, so cares about stability and integration; recognition could help careers |
Part C asked for a role whose position stays the same throughout the project, and the staff chose the CIO of GAS, high power and high interest throughout. The CIO owns the IT strategy and influences technology choices, budget approvals and regulatory requirements, and the project directly affects the company's IT modernisation and its competitiveness, so neither the power nor the interest depends on the project's phase. The contrast is with roles that move, the "positions on the grid move" pitfall of Part V: the IT Support Team's interest rises as handover approaches, and a CEO's interest could rise quickly if the project ran into trouble.
The agile reasoning question: the scooter fleet mock-up
The scenario was an electric-scooter fleet whose team, during Sprint 6, was asked for a "Mock-up Predictive Maintenance" feature for "Brake Pads": a quick, deliberately incomplete version of a dashboard that predicts when parts will fail. The staff present their answers as sample illustrative arguments rather than a complete list, so read them as examples of the kind of reasoning that scores.
Part A: what the Product Owner should do. Each action belongs to the PO for a reason you should give. The PO is accountable for the content and order of the Product Backlog (Part III) and writes the stories and their acceptance criteria (Part VI). When work is added to a sprint, the plan has to be cut back to its original size so that the Sprint Goal and a sustainable pace survive, and it is the PO who decides what gives way. And the PO is the channel through which stakeholders' knowledge reaches the backlog (Part V).
Part B: what the development team should do. The estimates come from the Developers because they own the sizing of the work (Part VI), and testing against the acceptance criteria is part of meeting the Definition of Done. The technical-debt item is the subtle point. Technical debt is the future work created by taking a shortcut now. A mock-up is deliberately incomplete, and recording the shortfall as a visible backlog item keeps it transparent, one of Scrum's three pillars, instead of letting it become the hidden inventory that a weak DoD creates.
Part C: QA criteria in BDD's Given–When–Then form. The staff give two criteria.
Given a dashboard accessible to authorised users, When an authorised user checks the Predictive Maintenance dashboard, Then the system should display an overview of predicted component failures, highlighting "Brake Pads" for the chosen scooter model.
Given the predicted failure of "Brake Pads" for the chosen model, When the system identifies a potential failure, Then it should generate an alert to the maintenance team specifying scooter model, component and predicted failure time.
Check yourselfA network has activities P (3 d, none), Q (5 d, none), R (4 d, after P and Q), S (2 d, after Q), T (6 d, after R and S). Find the critical path, the duration and the merge activities.
Paths: P–R–T = 3 + 4 + 6 = 13; Q–R–T = 5 + 4 + 6 = 15; Q–S–T = 5 + 2 + 6 = 13. The critical path is Q → R → T, 15 days. Merge activities (two or more immediate predecessors): R (P, Q) and T (R, S). Q is a burst activity (it feeds R and S).
Check yourselfIn a different scenario, a hospital's Chief Medical Officer chairs the steering committee of a new patient-records system and asks for weekly updates. Where would you place them on the grid, and how would you justify it?
High power, high interest: manage closely. Power: chairing the steering committee means they can approve, redirect or stop the project. Interest: asking for weekly updates shows the project matters to them directly. The pattern is the staff's: one piece of scenario evidence for power, one for interest, and quote the scenario where you can. (This is a new scenario for practice, not from the practice exam.)
Check yourselfWhich of these actions belong to the Developers rather than the Product Owner? (Select all that apply.)- Estimating the effort of the new mock-up stories
- Deciding which Sprint 6 stories are de-prioritised
- Testing the mock-up stories against their acceptance criteria
- Writing the acceptance criteria
A and C. The Developers own the sizing and the building and testing of the work. B and D belong to the Product Owner, who owns the backlog's content and order and defines the acceptance criteria (staff answer, Part A).
Check yourselfRewrite this weak criterion in Given–When–Then form: "The alert should be fast."
One possible answer (yours may differ): "Given a scooter whose brake pads are predicted to fail, When the system identifies the potential failure, Then it sends an alert to the maintenance team within [a time the scenario specifies], naming the scooter model, the component and the predicted failure time." The Then clause now has an observable, measurable outcome; take the number from the scenario rather than inventing one.
- PERT: draw the network, find the longest path (A–B–D–G–H, 33 days) and list activities with two or more predecessors as merges (D, E, H); add a line on why merges matter.
- Earned value: EV on top every time (the staff's fractions are inverted, their results right); name the cell (under budget, behind schedule) and explain it; EAC $482,664 (or $482,759 unrounded).
- Scenarios: name–prove–attach for ethics; one piece of evidence each for power and interest; PO decides what and in which order, Developers how and how much; Given–When–Then with a checkable Then. These answers are official, and rote-learning them is likely to attract low marks.