Back to blog

Scrum Explained: Roles, Events, Artifacts, and a Worked Cycle

与謝秀作

Scrum is a lightweight framework for addressing complex problems through usable results, observation, and adaptation. It provides a structure for learning what to build and how to work together. It is one way of applying Agile Development, not a synonym for Agile.

Scrum.org’s introduction explains the framework as incremental teamwork with experimentation and feedback.

Follow the cycle

Step

Activity

Information carried forward

Set direction

Clarify the product’s goal and candidate work

An ordered backlog

Plan

Discuss the purpose, selected items, and approach

A Sprint Goal and plan

Build and adapt

Complete usable work and revise the daily plan

Results and current evidence

Inspect the outcome

Discuss results and changes with stakeholders

Updated product choices

Improve the approach

Choose changes to working practices

An improvement to try

The Sprint Duration and Planning contains the other events and the work. It lasts no more than one month. Usable work can be released before the Sprint ends; the review is not a mandatory release gate.

Understand the accountabilities

Accountability

Main focus

Practical question

Product Owner

Maximize value and manage the Product Backlog

Which customer problem should come first?

Scrum Master

Establish Scrum and support team effectiveness

Which working conditions are blocking progress?

Developers

Plan and create usable work while maintaining quality

How should we adapt our plan to finish?

Developers include the professionals needed to create the result, not only programmers. See Scrum Master and Product Owner for a closer comparison of accountabilities.

Know the events and artifacts

The five events are the Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. They are not five separate meetings: the Sprint is the containing period. Sprint Review compares their purposes.

The three artifacts are the Product Backlog, Sprint Backlog, and Increment. Their associated commitments are the Product Goal, Sprint Goal, and Definition of Done. The Scrum Guide is the defining reference; Scrum Guide Summary offers a reading checklist.

A fictional first-cycle example

Imagine a team improving an application form. Its product direction is to make the application easier to complete. Candidate work includes investigating confusing inputs and improving error recovery. The Sprint Goal might be to establish a usable recovery path after an input error.

The team selects work that supports that goal, agrees required quality checks, creates a usable improvement, and discusses the outcome with stakeholders. It then examines how it worked and chooses an improvement for the next cycle.

Use User Story Templates to describe user value, Story Points and Planning Poker for optional estimation, Agile Velocity for forecasting from completed work, and Burndown and Burnup Charts for remaining-work visibility. Retrospective Frameworks and KPT Retrospectives provide retrospective approaches. These practices support a team’s work; they are not all mandatory elements of Scrum.

Avoid a calendar-only implementation

Placing individual assignments into two-week boxes does not create a shared purpose. Agree what the team wants to achieve or learn. Identify dependencies and quality checks early enough to finish usable work within the cycle.

For a comparison with phase-based delivery, see Waterfall and Agile. For workflow visibility, use the existing Kanban board guide. Xtrategy’s project management features connect campaign progress with costs and approvals when those operational decisions need to sit alongside delivery work.

Back to blog