Scrum Principles
Overview
Scrum is based on a set of Scrum principles and practices. In essence, these are summarized in the so-called manifest for agile software development, which was known in 2001 by leading software developers. The most important organizational and technical agile principles are summarized in this blog article.
Organizational principles
Self-organizing teams
Scrum calls for “self-organizing teams” and requires that traditional managers stay out of the production cycle of development as much as possible. The team is given as much co-determination as possible and the communication is on an equal footing. The expertise of the team members is used and their opinions, assessments and hints are taken seriously.
Changes are the rule and no exception
Scrum questions that requests can be pre-assembled on a larger scale. However, it is impossible to develop something without having documented what it should be. Therefore Scrum requirements are documented in the form of so-called user stories or epics. User stories are usually scenario descriptions. The description of requirements in the form of scenarios is particularly effective where much of the functionality is exhibited at the user interface. The scenario method has a significant advantage over other methods: it is easy to derive the associated test cases from the scenarios.
Scrum assumes that the customer often does not know or knows what he really needs. It is therefore assumed that the customer’s requirements and expectations change as the project progresses. Only for the duration of a “sprint”, i.e. a development cycle, are the requirements frozen.
The customer is closely involved in the development process
Customers are involved early in the development. You will be presented solutions developed in short intervals. The customer can then quickly give feedback on whether the solution meets his expectations.
Avoid overtime
Scrum wants to avoid that towards the end of the project, the promised delivery date is met with the help of overtime. The solution proposed by Scrum is simple: the deadline is kept and the delivered scope of functions is reduced if necessary. However, this solution is not possible in all cases, especially since a certain date is a necessary functionality to deliver. Overtime often results from unpredictable disruptions or miscalculations of effort. Experienced managers therefore plan with buffers and not overtime.
Development effort is minimized
Scrum requires, that only what is necessary be implemented, because users are expected to use only a fraction of the capabilities provided by a system. To keep development costs low, Scrum focuses on creating tests and software code and spends little time developing requirements and design
Technical Principles
Develop iteratively in short cycles
One of the Scrum principles is to divide the software production process into equally long phases of something one to four weeks duration called “sprints”. After each sprint, a functional product increment should be created that the customer can assess and what he can give feedback. This procedure is intended to avoid undesirable developments and to better meet customer expectations. During a cycle, the requirements must not be changed.
Automated tests are a key element
In Scrum great emphasis is placed on executable tests. The emphasis in testing is on the so-called “unit tests”, in which individual modules or classes are tested. Regression tests are intended to prevent errors in code modifications from being introduced into an already executable software module. No new software should be developed as long as existing tests still show errors.
First create tests
Another of the Scrum principles is the idea to create the corresponding test cases before the development of a feature and to include them in the suite of regression tests. This approach encourages thinking about proving the implementation of the requirements and thus supports the requirements engineering process. Developing tests first is therefore a helpful principle.
Scenario-based requirements
Scrum questions that requests can be pre-assembled on a larger scale. However, it is impossible to develop something without having documented what it should be. Therefore Scrum requirements are documented in the form of so-called “user stories” or “epics”. User stories are usually scenario descriptions. The description of requirements in the form of scenarios is particularly effective where much of the functionality is exhibited at the user interface. The scenario method has a significant advantage over other methods: it is easy to derive the associated test cases from the scenarios.
