BISM1201 Chap.5 Systems Development: Waterfall, Agile and Scrum
Systems Development: Waterfall, Agile and Scrum
Systems development turns a business need into a working and supported capability. Predictive approaches emphasise defined stages, early requirements, plans and traceability. Iterative approaches deliver smaller increments, gather evidence and adapt priorities. Scrum organises iterative work through a product goal, ordered backlog, defined accountabilities, recurring events and a usable increment.
Method labels do not guarantee good practice. Selection depends on requirement stability, feedback access, technical and regulatory risk, change cost and the need for formal approval. A hybrid can preserve strict controls around security or data while iterating uncertain user workflow.
What this chapter covers
- 01
Requirements, design, build, test and deployment
- 02
Predictive planning and change control
- 03
Iterative increments and stakeholder feedback
- 04
Scrum accountabilities, backlog and definition of done
- 05
Method fit, hybrid controls and operational readiness
Iterating a volunteer booking service
- +1Fix stable security, identity, capacity and audit requirements.
- +1Build a small authenticated view-and-book increment with acceptance criteria.
- +1Review it with coordinators and observe uncertainty around swap approval.
- +1Reorder the backlog so the risky approval flow precedes optional reminders.
- +1Test controls, train users and define support before expanding the pilot.
Key terms
- Predictive approach
- A development approach that plans defined stages and baselines requirements where later change carries visible cost and approval.
- Iterative approach
- A development approach that builds and reviews increments so evidence can refine needs, priorities and design.
- Product backlog
- An ordered and evolving list of product work that reflects value, risk, learning and the product goal.
- Product owner
- The Scrum accountability responsible for maximising product value through the product goal and backlog ordering.
- Scrum Master
- The Scrum accountability that establishes effective use of the framework, facilitates improvement and helps remove impediments.
- Definition of done
- A shared quality standard that determines when an increment is complete, transparent and potentially usable.
Systems Development: Waterfall, Agile and Scrum FAQ
When is a predictive approach appropriate?
It fits better when requirements are stable, formal traceability matters and late change is expensive. Stakeholder validation and testing still matter; predictive planning does not justify ignoring new evidence.
What makes an iterative project genuinely iterative?
The team produces working increments, reviews them with relevant stakeholders and adapts the backlog from evidence. Short time periods without usable output or changed decisions are not meaningful iteration.
Who decides backlog priority in Scrum?
The product owner is accountable for ordering the backlog to maximise value and support the product goal. Stakeholders and developers contribute evidence, while the Scrum Master supports the framework rather than choosing product value.
Can a project combine predictive and iterative controls?
Yes. A project may baseline security, legal or data requirements while iterating uncertain user experience. The combination should be justified by risk and learning needs, not chosen merely to avoid a clear governance decision.
Exam move
Make a comparison table using requirement stability, feedback speed, risk, change cost and evidence. Apply it to five short scenarios and justify one method or hybrid. For Scrum questions, distinguish accountabilities and explain how backlog, increment, review and adaptation connect.
Always add deployment support, training and monitoring so development is not treated as ending at go-live.
Create scenario cards that vary one condition at a time: stable versus evolving requirements, frequent versus scarce user access, low versus material failure impact, and cheap versus expensive late change. Choose an approach and state the reason in one sentence.
Then change one condition and decide whether the governance emphasis should change. This prevents Waterfall and Agile from becoming fixed industry labels.
Practise Scrum as an evidence loop. Write a product goal, three ordered backlog items and acceptance criteria for the first item. Describe the increment that would demonstrate value, the stakeholder feedback sought and the backlog change that could follow.
Add a definition of done covering testing, review and support readiness. If the feedback cannot change a decision, refine the review question.
For predictive practice, trace one requirement through design, test and approval. Introduce a late change and assess scope, risk and schedule impact before updating the baseline. Compare that evidence with an iterative increment.
A strong answer can explain what each approach makes visible and what it makes costly. Finish every case by naming the operational owner, training need, monitoring signal and improvement path after deployment.
Use an evidence ledger for a simulated project. Record the decision each artefact supports: approved requirement, prototype feedback, passing test, accepted increment or readiness review.
Mark evidence that is stale, incomplete or unable to change a decision. Then compare progress reported as activity with progress demonstrated by reduced uncertainty. This exercise clarifies why neither a detailed plan nor a busy sprint board proves that useful, supportable capability has been delivered.
