Someone once said that Scrum can be summarized as a framework on a single DinA-4 sheet. At least this applies to the clear and comparatively simple rules of Scrum, especially since they comprise only three roles, three artifacts and five activities. This is one of the reasons why this agile development method is so popular at the moment. Because there are only a few restrictive rules in Scrum, this method of agile software development can be introduced in companies without a long lead time.
Scrum is simple, but not trivial
Conversely, this does not mean that Scrum is more trivial than classical software development. Rather the individual Scrum rules have it in themselves, and a more exact preoccupation with it is of course indispensable for Scrum-Starter in the apron of the project. Then it quickly becomes apparent what the decisive differences are compared to traditional methods. In fact, Scrum even means a fundamental break with the rules of classical software development.
Here is a short overview of the rules in Scrum:
The Scrum Roles
- Product Owner: The product owner represents the interests of users and stakeholders and is responsible for the economic success of the project.
- Development team: The interdisciplinary team provides the product functionalities and is committed to compliance with the agreed quality standards.
- Scrum Master: The project master acts as moderator and service provider of the project team and creates the basic conditions for the successful course of the project.
The Scrum artifacts
- Product Backlog: This includes the requirements for the product in the form of a preliminary plan – this is dynamic and is subject to continuous further development.
- Sprint Backlog: Based on the product backlog, the tasks to be completed in each sprint can be viewed by all project participants.
- Product Increment: The product increment is the completed work package that is delivered to the product owner at the end of a sprint as a finished subproduct.
The Scrum activities
- Sprint Planning: Which new increment can be realized during a sprint, and how does the development team have to be composed for it?
- Daily Scrum: What is the current state of affairs and what possible obstacles have emerged in the course of the sprint?
- Sprint review: Was the development goal formulated in the Sprint Backlog 100 percent achieved from the product owner’s point of view?
- Sprint retrospective: Can the current way of working be improved?
- Product Backlog Refinement: To what extent can the plan or product vision recorded in the product backlog be improved on the basis of new knowledge?
In any case, it is important to internalize and follow the differences between the Scrum rules and methods of classical software development.
Otherwise, for example, a wrong understanding of roles can have an extremely negative effect on the entire course of the project. For example, there is no superordinate project manager in Scrum – so if Product Owner or Scrum Master overinterpret their respective roles, problems and conflicts that endanger projects are pre-programmed.