SCRUM vs waterfall, UML and user stories assignment guide

The four exercises are a dependency chain, not four separate tasks, and that changes how you should spend your time. The user stories feed the product backlog; the product backlog is what the sprint backlog is drawn from. A vague or duplicated set of stories therefore produces a backlog that cannot be prioritised sensibly and a sprint that cannot be sized, and the failure only surfaces two exercises after the mistake was made. Write the fifteen stories carefully — spread across real roles, each independently valuable, each small enough to estimate — and the two backlogs become largely mechanical. Write them in twenty minutes and you will spend an hour trying to rank fifteen items that are all the same size and all apparently equally important. The exercises are also weighted by effort rather than by marks, so the diagram is quicker than it looks and the stories are slower.

The story format is given in full and its third clause is the one that gets dropped. "As a (role), I want or need (functionality), so that I can (justification or benefit)" — the benefit clause is what makes prioritisation possible, because you cannot rank items by value if none of them states a value. It is also what stops a story becoming a task: "as a developer, I want to create the database schema" has a role and a functionality and no benefit to any user, which is a sign it belongs in the technical breakdown rather than the backlog. The case study gives you a rich set of roles — clinicians, nurses, health visitors, receptionists, medical records staff, administrators, health service managers — and using several of them is the cheapest way to get fifteen genuinely different stories rather than fifteen phrasings of three.

Question one has a constraint that is easy to miss under the word limit: your analysis should be more comprehensive than the initial considerations you addressed in Week 1. In 225 words that rules out the standard comparison table. What earns the extra credit is a dimension the introductory version does not reach — how requirements volatility determines which model is appropriate, how each handles a defect found late, what each assumes about the availability of the customer, or the observation that this particular case study is a poor waterfall candidate because its safety and privacy requirements are stable while its reporting requirements are not. Pick one such axis and develop it properly rather than listing five differences briefly. Two hundred and twenty-five words is roughly three paragraphs, which is enough for a claim, an illustration drawn from the case study, and a qualification that shows you know where the claim stops holding.