Build Something
That Matters.

Which Product Creates More Value?

Campus advice service · hypothetical teaching scenario

The pilot outcome is invented for this teaching scenario. Option B has a clearer connection to the stated waiting problem. Its value still depends on evidence, reliability and whose needs it serves. A larger feature list alone does not establish value.

Three Questions for Today.

These are the three Lecture Learning Outcomes. The exit check returns to them. Today introduces adaptive delivery through an example; detailed Scrum mechanics and planning methods come later.

Develop a Product. Show Your Contribution.

Practise the technical judgement, teamwork and responsibility needed for Level 6 project work.

A shared product does not make individual responsibility disappear. Contribution evidence can include an implemented change, a design decision with reasons, or a recorded test and its findings. The formal assessment briefs specify the evidence requirements.

One Journey. Two Semesters.

In-person Class Test: centrally scheduled outside normal teaching. Date, time and venue to be announced.

The journey combines product work, feedback and reflection across the year. Part B and Sprint Review 2 share the S1 Week 12 seminar session but are separately assessed. S2 Week 12 final verification adds no mark. The Class Test is not held in the normal Week 12 lecture.

Know the Purpose of Each Assessment.

Part D totals 50%: five Sprint Reviews at 8% each, plus the In-person Class Test at 10%. Reviews take place in S1 W10, S1 W12, S2 W5, S2 W8 and S2 W11. The Class Test is centrally scheduled; date, time and venue will be communicated separately. The Part A Defence clarifies understanding where required and has no separate numerical mark.

Your First Milestone: Part A.

Use the mandatory Project Proposal Template provided with the current brief. The exact submission date is published on the student website. Today introduces the purpose and first preparation steps; the Seminar explores the brief and rubric. Your Four-Line Idea Card today is formative, and you are not committing to a final product idea.

Which Evidence Belongs Where?

Work with a neighbour. Match each example to its primary assessment purpose.

This is a formative matching exercise, not an assessment question. Discuss the purpose before checking the explanation. In particular, distinguish communicating the group project in Part B from demonstrating product and individual contribution evidence in the Sprint Reviews.

The Project Creates and Improves the Product.

Finishing the work does not, by itself, prove that users benefit.

A project has a defined purpose and a beginning and end. A product can continue to be used and improved after a particular project ends. In computing, a product can be software, a system or a service. The same distinction applies to the campus queue example.

A Feature Is Not a Benefit.

These are intended effects in a teaching scenario. Evidence is needed to establish whether they occur.

A feature describes something a product can do. An output is a delivered result, such as the implemented alert. An outcome is a change resulting from use. A benefit is an improvement valued by a stakeholder. The chain is a hypothesis until evidence supports the connections.

Value for Whom?

Stakeholders can value different changes. An alert sent too early might reduce time at the desk but increase missed appointments. These are hypothetical effects. Check outcomes for affected stakeholders rather than choosing a single convenient success measure.

Classify the Claim.

Use each label once: project, feature/output, outcome, benefit, assumption.

1. Build and evaluate a queue service over six weeks.
2. The service sends a call-back alert.
3. Students spend less time waiting at the desk.
4. Students have more control over their time.
5. Students will notice the alert and return in time.

The statements describe a hypothetical product; they are not verified findings. An outcome is a change, while a benefit explains why the change matters. The claim about returning in time is an assumption that could fail even when the alert feature works.

What Do We Still Not Know?

A promising idea still contains unanswered questions.

An uncertainty is something we do not yet know. Name it explicitly rather than burying it inside a feature list. Useful evidence could come from observation, service records, interviews or a small trial. Detailed requirements discovery begins in Week 2.

New Evidence Should Change the Plan.

Adaptive delivery still involves planning. Evidence helps us revise it.

The trial is hypothetical. When important needs or solutions are uncertain, a small step can expose a weak assumption before extensive development. A predictive approach plans more of the work in advance where requirements are sufficiently understood; this example illustrates why an adaptive approach can help. It does not require detailed Scrum knowledge.

Turn a Vague Idea into a Useful Starting Point.

Keep this Four-Line Idea Card for your Seminar. Identify a possible benefit, not a promise that the product will succeed. No final project choice is assessed in this lecture. Give peer feedback on specificity and reasoning, not on how technically impressive the idea sounds.

Leave with a Direction, Not Just an Idea.

Use the three exit questions to check the Lecture Learning Outcomes. Your individual skills baseline is developed in the Seminar using examples from previous work. Keep one unresolved question alongside your Four-Line Idea Card. The current Module Guide and assessment documents on the student website remain the source for formal requirements.