Compare software development methodologies, including waterfall, agile and scrum, and identify when each is appropriate

Waterfall is a sequential methodology. The project moves through fixed phases in order: requirements, design, implementation, testing, deployment, maintenance. Each phase produces documents that feed the next. You do not revisit earlier phases without a formal change request.

Appropriate: a defence contract with fixed requirements, a building regulation system where the rules are legally locked, embedded firmware for a medical device where every requirement must be traceable.

Not appropriate: a new consumer web app where user feedback will reshape priorities, a startup MVP where the product is still being discovered, any environment where requirements change faster than the project plan can be updated.

Agile is iterative. The project is broken into short iterations (typically 1-4 weeks). Each iteration produces a working slice of software. Requirements are revisited continuously. The team reflects after each iteration and adjusts.

Appropriate: a customer-facing app whose users will be invited to use early versions and give feedback, a digital product whose competitive landscape changes monthly, a team that needs to deliver value within months not years.

Not appropriate: contracts that require a fully specified deliverable up front, regulated environments that demand documented sign-off at each phase, safety-critical systems where each change requires formal verification.

Markers reward both methodologies named correctly, their core mechanic (sequential vs iterative), concrete suitability examples, and the recognition that methodology choice depends on requirements stability, regulatory context, and team size.

Methodology: waterfall.

Justification: the requirements are fully known and locked into a signed contract, so there is little benefit to iterating on them. The mandatory phase sign-off by an independent auditor matches waterfall's sequential phase-gate structure, where each phase (requirements, design, implementation, verification) produces a document that is formally reviewed before the next phase starts.

Marking criteria: 1 mark for naming waterfall, 1 mark for linking the fixed contract/locked requirements to waterfall's sequential nature, 1 mark for linking the audit sign-off requirement to waterfall's phase-gate structure.

The four ceremonies: sprint planning, daily stand-up, sprint review, sprint retrospective.

Explanation (any one, e.g. sprint retrospective): held at the end of the sprint, the whole team reflects on what went well, what did not, and agrees one or two concrete changes to try in the next sprint. Its purpose is continuous process improvement, not reviewing the product itself (that is the sprint review's job).

Marking criteria: 1 mark for all four ceremonies named correctly, 2 marks for a correct explanation of the purpose of the chosen ceremony (not just its name or timing).

(a) Average velocity.

(b) Sprints needed.

Marking criteria: 1 mark for correctly summing the four sprints (79), 1 mark for the correct average (19.75), 1 mark for correctly dividing the remaining backlog by the average, 1 mark for rounding UP to a whole number of sprints with a reason given.

Kanban suits this team better. Support tickets arrive continuously and unpredictably, which does not fit neatly into a fixed 2-week sprint commitment; a ticket that is urgent on Tuesday cannot wait for the next sprint planning session. Kanban's continuous flow with a visual board and work-in-progress limits lets the team pull the next highest-priority ticket as soon as capacity is free, and WIP limits stop the queue of "in progress" tickets from growing unmanageably.

Scrum would force the team to estimate and commit to a fixed sprint backlog of tickets, but new high-priority tickets arriving mid-sprint would break that commitment repeatedly, undermining the sprint's purpose.

Marking criteria: 1 mark for correctly identifying kanban as the better fit, 1 mark for explaining continuous/unpredictable flow versus fixed sprint commitment, 1 mark for referencing WIP limits or the visual board specifically, 1 mark for explaining why scrum's sprint commitment breaks down in this context.

A hybrid keeps a high-level waterfall plan for the parts that are non-negotiable: the legally required payroll reporting fields and calculations are captured as a locked set of requirements up front, with formal sign-off and traceability from requirement to test, just as a compliance auditor would expect from pure waterfall.

Inside that outer plan, the implementation is broken into agile sprints. Each sprint delivers a working slice, for example the leave-accrual calculation in sprint 1 and the payslip generation in sprint 2, which stakeholders can review and give feedback on early, rather than waiting until the whole system is built to discover a usability problem.

This satisfies compliance (the legally mandated calculations are fixed, documented and tested before release) while still getting the faster feedback and reduced late-stage risk that comes from agile's iterative delivery of working software.

Marking criteria: 1 mark for describing the outer waterfall layer holding the locked/compliance requirements, 1 mark for describing the inner agile sprints delivering working slices, 1 mark for a concrete payroll example, 1 mark for explaining how compliance is satisfied, 1 mark for explaining how feedback speed improves.

This is a 6-mark ASSESS: markers reward a supported judgement, not a description of scrum alone.

Plan. Thesis: scrum, used unmodified, is poorly suited to this context, because its core strength (revisiting requirements mid-stream) directly conflicts with the TGA's demand for fixed, fully traceable requirements; a heavily gated waterfall (or a waterfall outer layer with agile only inside implementation) is more appropriate.

Model paragraph. Scrum's central value is the ability to change direction between sprints as the team and stakeholders learn more, which is exactly the property a life-critical, regulator-audited device cannot tolerate: every requirement must trace to a verified test BEFORE release, so requirements cannot be discovered or revised late in development without re-triggering the full verification chain. Scrum's short sprints and lightweight documentation also work against the TGA's expectation of a complete, signed-off design history. Waterfall's sequential phases, each producing a reviewable document with a formal gate, match the traceability requirement directly: requirements are captured once, verified through design and implementation, and independently tested before deployment. However, a purely rigid waterfall risks late discovery of implementation problems, so many regulated device teams in practice use a hybrid: the requirements and verification plan are locked in a waterfall-style gated process to satisfy the TGA, while internal engineering tasks (e.g. writing and unit-testing individual modules) may still use short internal iterations, provided every change still routes back through the same formal verification gate before it counts as "done". On balance, scrum in its standard form is not suitable for the pacemaker's release process itself, though agile-style internal engineering discipline can still improve code quality within a waterfall-governed outer structure.

Marker's note: top-band answers (1) explicitly weigh scrum's strength (adaptability) against why it is a liability here, (2) connect the TGA traceability requirement to a specific waterfall feature (phase gates, signed documents), (3) acknowledge a nuanced hybrid rather than a blanket "scrum is bad", and (4) end with an explicit judgement.

Methodology: scrum, run over four 2-week sprints, aligning naturally with the mid-project demo falling at the end of sprint 2.

Ceremony plan.

• Sprint planning (30 minutes, start of each sprint): the team agrees a sprint goal and selects backlog items, sized to the least available member's realistic hours rather than the most available, to avoid over-commitment.
• Daily stand-up (10 minutes, async text update if a live call clashes with timetables): each member states progress, next step, and blockers, so uneven skill levels surface early rather than at the deadline.
• Sprint review (end of each sprint): a short demo to the tutor (acting as product owner), producing the exact "stakeholder feedback" evidence the rubric rewards.
• Sprint retrospective: the team names one process problem (e.g. one member is consistently blocked waiting on another's module) and agrees a concrete fix, such as pairing the stronger and weaker coder on the next sprint's hardest ticket.

Addressing student-specific risks. Availability clashes are managed by keeping stand-ups asynchronous and sprints short enough (2 weeks) that a single missed week does not derail the whole project. Uneven skill levels are managed by having the product owner (tutor) and scrum master (a rotating team member) split backlog items by both priority and estimated difficulty, deliberately assigning a mix of easier and harder tickets to each person each sprint, and using the retrospective to reassign or pair on tickets that stalled.

Why not waterfall. With only eight weeks, a waterfall requirements-then-design-then-build sequence would leave no time to recover from a wrong assumption discovered late; scrum's early working slices and the mandated mid-project demo give the team (and the marker) visible evidence of progress and adaptation well before the deadline.

Marking criteria: 1 mark for justifying scrum over waterfall for this timeframe, 1 mark for a coherent sprint length/count that fits 8 weeks, 2 marks for a ceremony plan that names purpose not just labels, 2 marks for concrete strategies addressing availability clashes AND uneven skill levels, 1 mark for explicitly linking sprint review to the mid-project demo requirement.