Back to the Academy

Agile Projectmanagement

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.
To the video
Unsere Förderer
hallo@xlab.center
Moltkestraße 30
76133 Karlsruhe
© 2021 Innovate e.V. [x]Lab der Hochschule Karlsruhe
© 2021 Innovate e.V. [x]Lab der Hochschule Karlsruhe
menu-circlecross-circle linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram