Agile methods were primarily developed in software development, where innovation moves quickly and the desired end result is often not clearly defined by either customers or developers from the outset. Therefore, one of the fundamental principles of agile project management is working in short iteration cycles. Agile project management focuses on the emerging product and its acceptance by users, which is why they are much more involved in the product development process. Additionally, less planning should lead to faster implementation, greater adaptability, and increased responsibility.
Scrum
Scrum is just one of many specific frameworks for conducting agile project management and supporting effective team collaboration on complex products. Scrum consists of various roles, events, artifacts, and the rules that connect them. The framework uses the scientific method of empiricism and relies on iterative, incremental cycles to deal with unpredictability and help teams learn from empiricism..
Scrum-Team
The Scrum team is a cross-functional and self-organizing team consisting of 10 or fewer individuals. Self-organizing means that the team internally decides which person does which tasks when and how. Cross-functional teams have all the necessary competencies to complete the work without relying on external parties. The Scrum team consists of a Product Owner, developers, and a Scrum Master. All three roles are responsible for the success of a project, as they cover different aspects in the development of a new product.
The Product Owner is responsible for the so-called Product Backlog. In this, he/she manages content or features of the product (also called User Stories) and prioritizes them in collaboration with developers based on customer value and implementation effort. This way, developers are not overwhelmed with work, and customers receive the features they most desire first. The focus of the Scrum team is to implement the prioritized features as best as possible.
The Scrum Master ensures smooth implementation, provides the team with necessary resources, and ensures quick implementation of features so that customers can access them as soon as possible, and the Scrum team can learn through continuous exchange with customers. The Scrum Master organizes events such as Scrum Planning, Daily Scrum, Scrum Review, and Scrum Retrospective, among others.
Scrum Events
Defined events with a predetermined time frame are used in Scrum to create regularity and make other meetings that are not provided for in Scrum obsolete. The duration of a sprint is fixed and cannot be shortened or extended once it begins. All other events, however, can end once the purpose of the event is fulfilled.
Sprint
A sprint has a time window of one month or less in which a finished, usable and Scrum-released product increment is created - and begins immediately after the completion of the previous sprint. The sprint goal dictates what is built based on a flexible plan. During the sprint, quality goals are not reduced and no changes are made that would jeopardize the sprint goal. The scope of the sprint can be clarified and renegotiated between the product owner and the developers if new insights arise.
Sprint Planning
The work to be done during the sprint is planned during sprint planning. This plan is created by the entire Scrum team. Sprint planning is set to a maximum of eight hours for a one-month sprint - for shorter sprints, the event is usually shorter. The Scrum Master ensures that the planning takes place within the specified timebox and that the team understands the purpose. The sprint planning answers the following questions: What can be delivered in the resulting increment (sprint goal)? Why do we want to achieve this goal? How will the work required to deliver the increment be achieved?
The sprint goal is a goal that is set during planning for the respective sprint and can be achieved through the implementation of the product backlog. This goal is a kind of guide for the developers and clarifies why the increment is being created.
Daily Scrum
Daily Scrums are daily 15-minute meetings of the developers to coordinate the last and upcoming 24 hours. They are important inspection and adaptation meetings. Because they improve communication, make other meetings unnecessary, identify development obstacles, show and promote quick decisions, and improve the knowledge of the developers. The Scrum Master only ensures that the developers have the meeting within the specified timebox. The structure of the meetings is determined by the developers themselves and can be carried out in different ways as long as it focuses on progress towards the sprint goal. The "Daily Scrum" is an internal meeting for the developers. If others are present, the Scrum Master ensures that they do not disturb the meeting.
Sprint Review
At the end of each sprint, a sprint review is held. The increment is inspected with the stakeholders and the product backlog is adjusted if necessary. Based on this, the participants work out which steps can be taken next to optimize the value of the increment. The presentation of the increment is intended to receive feedback and promote collaboration. Therefore, the reviews are not status meetings, but meetings with an informal character.
For one-month sprints, reviews have a maximum length of four hours. For shorter sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that the participants understand the purpose of the event. The result of the sprint review is a revised product backlog that defines the likely product backlog items for the next sprint. The product backlog can also be adjusted as a whole to meet new opportunities.
The sprint review includes the following elements:
- The participants include the Scrum team and important stakeholders invited by the product owner. - The product owner explains which product backlog items have been completed and which have not. - The product owner presents the current state of the product backlog and projects probable target and delivery dates based on progress to date (if necessary). - The developers discuss what went well during the sprint, what problems they encountered, and how those problems were solved. - The developers demonstrate the work they have done and answer questions about the increment. - All participants work on what to do next so that the sprint review provides valuable input for the subsequent sprint planning. They review the schedule, budget, potential capabilities, and market for the next expected releases of functionality and capabilities of the planned product.
Sprint Retrospective
The sprint retrospective is an opportunity for the Scrum team to review and improve their own development process and practices to make the next sprint more effective and enjoyable. During each sprint retrospective, the Scrum team plans ways to increase product quality by improving work processes or adjusting the definition of "done" if appropriate and not in conflict with product or organizational standards. The retrospective takes place after the sprint review and before the next sprint planning. For one-month sprints, this is a maximum of a three-hour event - for shorter sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that the participants understand the purpose. During the sprint retrospective, the team discusses: What went well in the sprint? What could be improved? What will we do in the next sprint to improve? At the end of the sprint retrospective, the Scrum team should have identified improvements that it will implement in the next sprint.
Scrum Artifacts
The artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. The artifacts defined by Scrum are specifically designed to maximize the transparency of key information so that everyone has the same understanding of the artifact. The Scrum artifacts are: Product Backlog, Sprint Backlog, and Increment.
Product Backlog
In Scrum, features are formulated as user stories from the perspective of customers and stored in the Product Backlog in the following format: "As [position], I need [feature], so that I [benefit]." In the earliest development phase, the initially known and best understood requirements are recorded. The Product Owner and the developers continuously work on the details of the Product Backlog items and determine what the product needs to be appropriate, competitive, and useful. Therefore, the Product Backlog is very dynamic and constantly changing. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
Sprint Backlog
The Sprint Backlog consists of Product Backlog items selected for the respective sprint. The Sprint Backlog is a prediction by the developers of what functionality will be included in the next increment and what work is required for it. The Sprint Backlog makes all the work visible that the developers identify as necessary to achieve the sprint goal. To ensure continuous improvement, it includes at least one high-priority process improvement identified in the previous sprint retrospective. The Sprint Backlog is a plan that is detailed enough to track changes in progress during the Daily Scrum. Developers modify the Sprint Backlog during the sprint. Only developers can change their Sprint Backlog during a sprint.
Increment
The purpose of each sprint is to deliver increments of potentially releasable functionality. An increment is the sum of all the Product Backlog items completed during a sprint. At the end of a sprint, the new increment must be finished, meaning it must meet the Scrum Team's definition of "done" and be in a usable state. Therefore, it is clearly defined when an item from the Sprint Backlog is considered completed or "done." This increment is usable, so a Product Owner can decide to release it immediately. If the definition of "done" for an increment is part of the development organization's conventions, standards, or guidelines, all developers must follow them at least.
Kanban vs. Scrum
Kanban is an alternative framework for implementing agile project management. As with Scrum, iterative product development and continuous feedback from users are the focus. However, unlike Scrum, Kanban does not have regular sprint cycles in which selected features are developed. Instead, a Kanban board is used to regulate when further features are developed. A clear explanation is provided in the video.
Um die Webseite optimal gestalten und verbessern zu können, verwenden wir Cookies. Genauere Informationen sind in unseren Datenschutzbestimmungen zu finden.
Diese Website verwendet Cookies, um deine Erfahrung zu verbessern, während du durch die Webseite navigierst. Von diesen werden die als notwendig eingestuften Cookies in deinem Browser gespeichert, da sie für das Funktionieren der grundlegenden Funktionen der Webseite unerlässlich sind. Wir verwenden auch Cookies von Dritten, die uns helfen zu analysieren und zu verstehen, wie du diese Webseite nutzt. Diese Cookies werden nur mit deiner Zustimmung in deinem Browser gespeichert. Du hast auch die Möglichkeit, diese Cookies abzulehnen.
Notwendige Cookies sind für das ordnungsgemäße Funktionieren der Website unbedingt erforderlich. Diese Cookies gewährleisten grundlegende Funktionalitäten und Sicherheitsmerkmale der Website.
Cookie
Dauer
Beschreibung
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Funktionale Cookies helfen dabei, bestimmte Funktionen auszuführen, wie z. B. das Teilen von Inhalten der Website auf Social-Media-Plattformen, das Sammeln von Rückmeldungen und andere Funktionen von Dritten.
Performance-Cookies werden verwendet, um die wichtigsten Leistungsindizes der Website zu verstehen und zu analysieren, was dazu beiträgt, den Besuchern ein besseres Nutzererlebnis zu bieten.
Analytische Cookies werden verwendet, um zu verstehen, wie Besucher:innen mit unserer Webseite interagieren. Diese Cookies helfen uns bei der Bereitstellung von Informationen über die Anzahl der Besucher:innen, die Absprungrate, die Verkehrsquelle usw.