What is Scrum?
Scrum is an agile process model that was originally developed for software development, but is now used in many other areas. Large task complexes are divided into small components, so-called increments. Scrum focuses on the user's view of the requirements. All these requirements (= product backlog) are developed in intervals of usually 1 to 4 weeks, the so-called sprints (development cycle). This provides interim results that serve as the basis for the next development steps. In principle, a finished sub-product (= product increment) should be delivered after a sprint. This is reviewed together in the so-called review meeting and the next sprint is planned in a subsequent planning meeting (= empiricism). This means that not only the product to be developed but also the planning itself becomes agile, iterative and incremental. This makes the main plan continuously more concrete and detailed: the main plan tasks (the product backlog) are divided into smaller task packages and assigned to individual sprints (sprint backlog).
This leads to continuous improvement in small to large steps, depending on the current requirements. Scrum is also iterative, meaning that processes are repeated. All of this distinguishes Scrum from conventional, rigid projects that are implemented 1:1 according to a previously created plan with sprawling specifications and requirements. The agile process model is particularly suitable for extensive projects, as experience has shown that detailed planning of all sub-aspects cannot be guaranteed. As a result, questions arise during implementation, requirements are changed and time, resources and financial means are overstretched.
Special advantages of Scrum:
- Transparency for everyone involved: development status and problems are regularly logged and are visible to everyone.
- Control: The functionalities are regularly checked and evaluated.
- Adaptation of requirements: The end product can be continuously improved through regular meetings (review meetings, planning meetings see below).
None of this makes Scrum a less complex approach, but it structures the work better, which is ultimately more cost-efficient. Scrum is designed for teams of 3 to 9 members, each of whom is assigned a role.
The Scrum role model
Scrum has defined roles with their own rights and areas of responsibility. However, these have nothing to do with the actual company hierarchy, but only with the technical suitability of the employees.
On the one hand, there is the client(product owner). This is usually the customer or a representative of the customer, who sets the technical requirements and assesses the developments. They take on the perspective of the ultimate user of the product. As they are responsible for the technical requirements, it is their task to maintain and prioritize the product backlog. He is also available for queries from the team.
The Scrum Master is responsible for ensuring that the Scrum process runs correctly. To this end, he is the link between the product owner and the development team. He ensures that obstacles (blockers) are removed. This could be a missing specification, for example, or a missing resource. He also moderates the scrum meetings and ensures that the team can work. They must keep an eye on both the product backlog and the sprint backlog.
The development team implements the requirements for the product. It consists of developers, but also testers, editors, etc. (interdisciplinarity). The team organizes itself, which means that it distributes tasks itself and solves them in the way it chooses. Once a product increment is complete, the team presents it at the review meeting. For Scrum to work, it is a top priority that the development team can work without obstacles.
Scrum meetings
In Scrum, there are different types of meetings that are attended by different participants. In order to keep the meetings and the entire process efficient, it is essential that times are adhered to. Sprints are planned and reviewed in the meetings. There are the following meetings:
Sprint planning meeting: this is where the product owner shows the highest-priority increments in the product backlog and decides together with the team which parts of the product backlog will make up the upcoming sprint backlog. The product owner and team agree on the acceptance criteria for the product increment to be developed. The team autonomously plans the upcoming sprint and the available resources and breaks down the requirements into individual tasks. Various techniques can be used for this (see below).
Sprint review meeting: Here, the team shows the product owner the development achieved in the last sprint. Functionalities can be reviewed and the product owner can provide feedback.
Daily Scrum Meeting: This short (15-minute) daily meeting is for the team to keep each other up to date. Questions are answered about what has been done since the last daily, what will be done before the next daily and what any blockers were that prevented the developer from working. The Scrum Master makes a note of these blockers and tries to solve them.
Retrospective meetings: These are used to look back and discuss what went well and what went badly and what would make the work better, more productive, more efficient and more enjoyable next time.
Sprints
A sprint or development cycle is planned and carried out jointly by the team. It is important that the team does not receive any new requirements for the increment within a sprint so that the team can work as efficiently as possible. How long a sprint lasts depends, among other things, on how quickly the developments can be carried out, how complex a sprint is and how high the requirements are. A sprint usually lasts 1 to 4 weeks. It ends with the sprint review meeting.
Helpful techniques
User stories
From the user's point of view, requirements are drawn up in the form of user stories. A user story could be, for example: As an employee in the company, I would like to have a cooling facility to store my lunch. The system is therefore: As a user, I want function and therefore benefit. User stories then form the product backlog and can be further specified there (product backlog refinement).
Planning poker
Since 2005, planning poker has been used to estimate the development effort required for individual tasks and user stories: Various values from easy to difficult or little to a lot are written on playing cards. The developers each estimate the effort required for a task with the help of the playing cards. At the same time, all the cards are revealed. The participants with the highest or lowest value are asked to give their reasons. In a subsequent discussion, a common estimate is agreed upon.
Further information
Our internet agency works with agile methods. If you would like to get to know us better, we look forward to hearing from you!
Book tips
