Transfer Task

If you think you already know the important methods, you can take the a short self-test.

Which roles are there in a scrum team?

Scrum Master
Project Manager
Product Owner
Product Developer
Team Leader

Who does what in a scrum team?

Grabbable 1 of 4.

Prioritize the product backlog

Grabbable 2 of 4.

Moderate scrum events

Grabbable 3 of 4.

Define the product

Grabbable 4 of 4.

Enforce scrum rules and regulations

Dropzone 1 of 2.

Product Owner

Dropzone 2 of 2.

Scrum Master

Input

Which frameworks are there for the description of agile methods? In this learning card you will get to know the most important agile methods and framework models.

Agile methods differ in their level of detail and formalization.

SCRUM is at the forefront of flexible framework models for agile work. At SCRUM, the development teams work on product development in a self-organized manner. Under the guidance of a SCRUM Master, they implement the specifications of the PRODUCT OWNER step by step.

KANBAN, SCRUMBAN and CRYSTAL are frameworks for agile work, which above all ensure efficiency in the processes. They stand for relatively simple methods for controlling the workflow and increase transparency.

FEATURE DRIVEN DEVELOPMENT (FDD), EXTREME PROGRAMMING (XP) and LEAN SOFTWARE DEVELOPMENT (LDS) focus on lean and function-oriented software development with integrated tests and feedback loops.

Software engineering models such as the V-Model or the Rational Unified Process Model have the highest degree of formalization and detailing.

SCRUM

SCRUM is a working method in which self-organized teams develop new products or product increments together in iterations according to certain rules.

Scrum Roles

In Scrum there are three central roles that interact with each other.

1. PRODUCT OWNER

The product owner is the one who determines the product properties and formulates the so-called EPICS and USER STORIES. A user story is a functional description from the point of view of a specific role, e.g.

As a [customer] I want a [visualization function] to have a [three-dimensional representation of a product so that I can imagine the product more precisely].

The Product Owner is responsible for product and release planning. He defines the product scope and prioritizes the user stories according to business value and benefit. However, he has no disciplinary authority over the development team. Product owners need above all professional and entrepreneurial skills.

2. SCRUM MASTER

The Scrum Master is the team coach for the Scrum team. He pays attention to the observance of the Scrum rules and moderates the Scrum events. He also has no disciplinary power over the Scrum Team, but acts as a coach and moderator. One of his central tasks is the removal of obstacles that prevent the development team from working on the product (e.g. missing licenses or access to other systems).
Scrum Masters need above all methodical and social skills.

3. DEVELOPER TEAM

The development team consists of 3 to 9 people, who self-organize the product features and user stories to be developed into work packages and transfer them into concrete (programming) tasks. In SPRINT PLANNING MEETINGs they plan the tasks and goals for the next sprint and appreciate the complexity of each user story. All tasks necessary for the realization and testing of a user story are planned and executed by the team itself. The team members need above all technical skills.

Artefacts in Scrum

The PRODUCT BACKLOG is the key document in which the product requirements are formulated and prioritized by the product owner in the form of EPICS (key topics) and USER STORIES. It is not a rigid specification, but can develop from sprint to sprint. New requirements can be included in the product backlog, already formulated user stories can be eliminated or their importance can be prioritized upwards or downwards. With the help of the product backlog, the product owner controls the product creation process.

Example of a Product Backlog

The SPRINT BACKLOG contains the worklist for the developer team for the next sprint. It contains the most prioritized user stories from the product backlog. The development team determines together with the product owner which user stories are to be realized in the next step and estimates their complexity. Depending on the effort and complexity of the user stories, the Sprint Backlog can contain more or less user stories.

Events in Scrum

In SPRINT PLANNING MEETINGS, the development team plans the steps necessary to implement the user stories from the Sprint Backlog. The team members discuss dependencies between the user stories and determine which work steps are necessary to achieve the sprint goal.

n an ESTIMATION MEETING, developers estimate the complexity of each user story and the effort involved in implementing the functions.
With DAILY SCRUM, the developers give each other a short daily report on the status of the tasks they have taken on. If necessary, problems are escalated via the Scrum Master to the Product Owner, e.g. if the sprint target is at risk.

In the SPRINT REVIEW, the development team presents the new functions developed in a sprint to the product owner. The product owner accepts or rejects the functions if they do not meet the agreed acceptance criteria ("Definition of Done").

In the RETROSPEKTIVE, the team looks back at the course of the past sprint. The aim of the retrospective is to improve teamwork and remove obstacles before the start of the next sprint. The retrospective is moderated by the Scrum Master.

Checklist for the evaluation of a sprint (www.retromat.org)

Special methods in Scrum

Subsequently you will get to know some special methods for the cooperation in Scrum Teams.

Kanban

KANBAN is a Japanese word and means "SIGNAL" or "SHIELD". It was originally introduced in LEAN MANAGEMENT for the control of production processes according to the "PULL" principle. On a KANBAN board, all tasks that have to be completed in a sprint are written on individual cards. Then they are pulled one after the other from left to right through the individual columns of the kanban board. Only if a place on the board is empty, a following card can be drawn on this place. This ensures a fast workflow in the system.

Planning Poker

At PLANNING POKER, the team members in the Scrum Team jointly estimate the complexity and time required for each user story. Planning Poker cards are often used for this. The story is read aloud and each team member draws a card from his or her card set, concealed, with which the effort for the realization of all functions belonging to a user story is estimated. Thean the cards are layed openly on the table at the same time.

If the estimates are far apart, the team members with the highest and lowest estimates must justify their decision. The other team members listen to the arguments and rethink their own estimates. After that they play poker again. The estimates should now converge.

In this way, all user stories to be realized in the next sprint are estimated and summed up in terms of their complexity and effort. This is the number of STORY POINTS to be realized by the team in the next sprint.

Sprint Review

In a SPRINT REVIEW, the development team introduces the product owner to the functions that have been developed and tested for the realization of user stories in Sprint. The product owner accepts the functions if they meet the agreed acceptance criteria. The accepted functions can then be transferred to the next release. Functions that are not accepted must be revised again in the next sprint according to the acceptance criteria.

Retrospective

In a RETROSPEKTIVE the Scrum team members reflect the quality of their cooperation and the results achieved in the sprint.
The following key questions can be used for structuring.

What went well? What positive experiences did we have in the last sprint?
What went badly? What negative experiences did we have in the last sprint?
What information and better communication do we need to be more effective as a team in the next sprint?
Which Scrum rules and principles did we pay particular attention to or neglect in this sprint?
What decisions do we make for the next sprint? What will we keep? What will we change?