The SDLC & Methodologies

Scrum: Roles, Events & Artifacts

18 min Lesson 5 of 10

Scrum: Roles, Events & Artifacts

Scrum is the most widely adopted Agile framework in the world. Rather than a rigid process, it is a lightweight empirical framework — one that embraces uncertainty and uses short feedback loops to steer a project toward value. Understanding Scrum deeply is essential for any systems analyst because it defines how your work (requirements, acceptance criteria, analysis artefacts) is organised, prioritised, and delivered in a modern software team.

The Three Scrum Roles

Scrum defines exactly three accountabilities. Everyone on the project fits into one of these roles — ambiguity in ownership is a common failure point.

Product Owner (PO)

The Product Owner is the single voice of the business. In a clinic booking system project, the PO might be the clinic operations manager who understands patient needs, regulatory constraints, and revenue priorities. Responsibilities include:

Owning and ordering the Product Backlog — deciding what gets built and in what sequence.
Writing or approving User Stories and their Acceptance Criteria so the team knows when "done" means done.
Maximising value delivered per sprint — constantly asking "will this item serve our patients and make the clinic more efficient?"
Being available to answer questions during the sprint, not just at the boundary meetings.

Analyst insight: In many organisations the systems analyst supports the Product Owner by conducting stakeholder interviews, writing detailed acceptance criteria, and maintaining traceability. The PO provides the "what and why"; the analyst provides the rigor.

Scrum Master (SM)

The Scrum Master is a servant-leader who protects the team's ability to deliver. They are not a project manager issuing orders; they remove obstacles — a blocked API credential, a meeting that could be an email, a recurring argument about definition of done. In our logistics firm example, the SM might notice that the warehouse integration team always causes a bottleneck in sprint review and negotiate a shared interface contract to resolve it permanently.

Development Team (Developers)

The cross-functional team that builds the product increment. In Scrum, "developer" means anyone who contributes to the increment — analysts, testers, UX designers, backend engineers, database specialists. The team is self-organising: they decide how to accomplish the sprint goal. A typical Scrum team is 3–9 people; beyond that, coordination cost outweighs the benefit.

The Five Scrum Events

Every Scrum event has a fixed maximum timebox. The timebox creates urgency and prevents endless deliberation.

The Sprint — the heartbeat of Scrum, a time-box of 1–4 weeks (commonly 2 weeks) during which the team creates a potentially releasable Product Increment. All other events happen inside the sprint.
Sprint Planning — the team selects items from the Product Backlog and commits to a Sprint Goal. Timebox: 8 hours for a 4-week sprint (scale proportionally). The team asks: "What can we deliver? How will we do it?"
Daily Scrum — a 15-minute synchronisation for the developers every working day. Classic three questions: What did I do yesterday? What will I do today? Is anything blocking me? The Scrum Master facilitates; it is not a status report to management.
Sprint Review — the team demos the working increment to stakeholders at the end of the sprint. Feedback flows back into the backlog. Timebox: 4 hours (2-week sprint). In the online store example, the team demonstrates a new "saved address" checkout flow to the marketing director and logistics head.
Sprint Retrospective — the team reflects on how they worked, not what they built. What went well? What to improve? One or two concrete experiments for the next sprint. Timebox: 3 hours. This is the engine of continuous improvement.

The Three Scrum Artifacts

Product Backlog — an ordered list of everything that might be needed in the product. Each item (a User Story, a bug, a technical task) is called a Product Backlog Item (PBI). The PO owns and orders it; the team refines it collaboratively. For the clinic system: "As a patient, I want to book an appointment online so that I avoid calling during peak hours" might be PBI #3.
Sprint Backlog — the subset of Product Backlog items the team has committed to for the current sprint, plus the plan for how to deliver them (often broken into tasks of ≤ 8 hours). It is owned by the developers, not the PO.
Increment — the sum of all completed PBIs. Each sprint adds to the increment. It must meet the team's Definition of Done (DoD) — for example: "code reviewed, automated tests passing, deployed to staging, acceptance criteria verified." The DoD is the team's quality contract.

Best practice — Backlog Refinement: Many teams hold a mid-sprint "refinement" session (not an official Scrum event but widely practised). The analyst leads the session: User Stories are estimated, split if too large, and have acceptance criteria clarified before they enter a sprint. This reduces planning chaos and prevents stories from being pulled in half-baked.

The Sprint Cycle — Visualised

The Scrum Sprint Cycle: Product Backlog feeds Sprint Planning, work executes inside the Sprint with daily synchronisation, and the Review feeds feedback back into the backlog.

Scrum in Practice — A Clinic Booking System Sprint

Imagine Sprint 4 of a clinic booking system project. The Product Owner has ordered three stories at the top of the backlog:

As a patient, I want to receive an SMS confirmation so I know my booking is confirmed. (8 story points)
As a receptionist, I want to view all appointments for a doctor on a daily calendar view. (5 points)
As an admin, I want to cancel appointments in bulk so I can handle doctor absences efficiently. (13 points)

During Sprint Planning the team's capacity is 18 points. They accept stories 1 and 2, take the first half of story 3 (the UI only — 8 points adjusted), and form a Sprint Goal: "Patients receive booking confirmations and receptionists can view daily schedules."

Each Daily Scrum surfaces a dependency: the SMS gateway credentials are delayed by IT procurement. The Scrum Master escalates to the IT director — the blocker is resolved by day 3. At Sprint Review, the clinic manager sees the live SMS confirmation working on a real phone and immediately requests a WhatsApp option — a new PBI is created and refined for a future sprint.

Common pitfall — "Scrum but": Many teams adopt Scrum selectively: "We do Scrum but we skip the retrospective" or "Scrum but the PO only attends the review." These omissions destroy the feedback loops that make Scrum work. A retrospective skipped means recurring problems never get fixed. A part-time PO means the backlog drifts from business reality.

The Analyst's Role Inside Scrum

Systems analysts typically operate as part of the development team or in close partnership with the Product Owner. Key analyst activities mapped to Scrum events:

Between sprints (refinement): Write User Stories, define acceptance criteria, identify dependencies, break down large epics into sprint-sized stories.
Sprint Planning: Clarify requirements, resolve ambiguities so the team can estimate confidently.
During the sprint: Answer clarification questions, validate in-progress implementations against requirements, update process models as design decisions are made.
Sprint Review: Observe stakeholder reactions, capture feedback, translate it into new or modified backlog items.
Retrospective: Reflect on requirements quality — were stories clear enough? Did late clarifications cause rework?

Tip — Three Amigos: Before a story enters a sprint, run a short "Three Amigos" session: the Product Owner (business perspective), a developer (technical perspective), and a tester (quality perspective) walk through the story together. Misunderstandings caught here cost nothing; caught during testing they cost days.