Scrum

I define Scrum as a lightweight process framework for agile product development. First, it focuses on delivering valuable increments. Next, it defines core parts such as roles, events, and artifacts. Then, it shows how teams handle requirements in day-to-day work. Finally, Scrum leaves many implementation decisions to the team.

I describe the three roles in simple terms. The Product Owner decides product content and backlog priorities. The Scrum Master supports the team by coaching and removing impediments, while safeguarding the framework. The Developers build the product and handle requirements-related tasks as part of delivery. In addition, the team organizes itself.

I explain the main artifacts. The Product Backlog holds user stories and other backlog items. The Sprint Backlog contains the selected items the team plans to complete in a sprint. The Increment represents the working product at the end of the sprint. Moreover, backlog entries often include attributes such as description, order, estimate, status, and value. In addition, teams can group items into epics.

I describe requirement items and traceability. For example, user stories often include acceptance criteria, so I link each story to its acceptance test cases. In addition, I can link stories to source code and to related backlog items. However, Scrum does not demand a formal traceability system. Therefore, I document traceability only when the team truly needs it.

I cover prioritization and estimation. First, the Product Owner orders the backlog. Then, Developers support estimation, for example with planning poker. As a result, items get ranked by value, risk, and effort. Next, the team selects items for the next sprint during Sprint Planning. Meanwhile, the team refines and reorders the backlog as new information appears.

I state the framework’s view on versioning. Teams usually do not version user stories in a formal way. Instead, the current story text serves as the single source of truth. Therefore, the focus stays on the latest, working description.

I give a short example of acceptance criteria in a simple conditional form: On condition that <PRECONDITION>, if <TRIGGER>, then <RESULT>. For example: On condition that there is more than €100 in my account, if I activate a transfer of €100, then the source account shows €100 less and the target account shows €100 more. Thus, requirements and tests stay closely linked.

I caution that Scrum covers only general work processes. It does not prescribe every activity for managing requirements. Therefore, I rely on the Scrum Guide for official definitions, while teams add tools, templates, and practices when needed. In conclusion, each Scrum team should decide how to implement requirements tasks. Consequently, the team owns both the process and the product.