Scrum

from Wikipedia, the free encyclopedia

Scrum (from English scrum for "crowd") is a procedural model of project and product management , especially for agile software development . It was originally developed in software engineering, but is independent of it. Scrum is now used in many other areas. It is an implementation of Lean Development for project management.

History and basics

The beginnings of Scrum can be traced back to Ikujirō Nonaka and Hirotaka Takeuchi . Inspired by their findings, Jeff Sutherland created a new role for the project manager in a project for Guinness Peat Aviation . They became team members and their role was more of a moderator than a manager. Together with Ken Schwaber he formalized Scrum from 1993. Scrum was influenced by the Theory of Constraints and the Toyoto 3M model ( Muda , Mura, Muri), the idea of ​​a daily meeting comes from James Coplien. The first conference contribution on Scrum was published at the OOPSLA 1995. In it Schwaber wrote: “Scrum accepts that the development process cannot be foreseen. The product is the best software in terms of cost, functionality, time and quality. "The term Scrum but comes from Nonaka and Takeuchi, the order that the crowds ( English scrum ) in rugby described as an analogy for exceptionally successful product development teams. These teams work as small, self-organized units and are only given one direction from outside, but determine the tactics themselves how to achieve their common goal.

In 2002 Ken Schwaber and Mike Beedle , one of the first Scrum users, published Agile Software Development with Scrum, the first book on Scrum, followed in 2004 by Schwaber's Agile Project Management with Scrum . In 2007, Ken Schwaber's third book, The Enterprise and Scrum, was published . This is no longer just about introducing Scrum into software development teams, but about expanding it to the entire company. At least since VersionOne's first annual survey (2006), Scrum has been the most common agile method .

Scrum parallels to be found in the lean production (English lean production ), which has its origins in Japanese companies. It strives for better value creation through increased cooperation. Nonaka and Takeuchi attribute the success of such companies to successful knowledge management. In the Western understanding, knowledge as a resource is limited to words and numbers. Knowledge can be acquired or trained according to this understanding. Japanese companies, on the other hand, see this type of knowledge only as the tip of the iceberg. For them, knowledge is primarily implicit (“tacit”). This tacit knowledge is subjective and intuitive, it contains our picture of reality and our vision for the future. While explicit knowledge is easy to represent and process, this is much more difficult with implicit knowledge. Companies like Toyota or Canon benefit from the implicit knowledge of their employees by placing a high value on the interaction between their employees.

In this context, Scrum can be seen as an alternative to the command and control organization, in which employees receive work instructions that are as precise as possible. Instead, Scrum builds on highly qualified, interdisciplinary development teams who are given a clear set of goals, but are solely responsible for implementation. This gives the development teams the freedom they need to develop their knowledge and creativity potential on their own.

Scrum embodies the values ​​of agile software development, which were formulated in the agile manifesto by Ken Schwaber, Jeff Sutherland and others in 2001 :

  1. Individuals and interactions are more important than processes and tools.
  2. Functioning software is more important than comprehensive documentation.
  3. Cooperation with the customer is more important than contract negotiations.
  4. Responding to change is more important than following a plan.

Scrum consists of only a few rules. These describe four events , three artifacts , and three rollers , the core (English core account). The rules are described in the Scrum Guide , there is another short description in the Agile Atlas. The Scrum framework must be concretized through techniques for the implementation of the events, artifacts and roles in order to actually implement Scrum. The core of Scrum was separated from the implementation techniques, on the one hand to clearly define the central elements and mechanisms of action, on the other hand to allow great freedom in the individual design.

The Scrum approach is empirical , incremental and iterative . It is based on the experience that many development projects are too complex to be put into a comprehensive plan. A significant part of the requirements and the possible solutions is unclear at the beginning. This ambiguity can be eliminated by creating intermediate results. Based on these interim results, the missing requirements and solution techniques can be found more efficiently than through an abstract clarification phase. In Scrum, planning is developed iteratively and incrementally in addition to the product. The long-term plan (the product backlog ) is continuously refined and improved. The detailed plan (the sprint backlog ) is only created for the next cycle (the sprint ). This means that project planning is focused on the essentials.

The empirical improvement is based on three pillars:

  1. Transparency : the progress and obstacles of a project are recorded regularly and visible to all.
  2. Review : Project results and functionalities are regularly delivered and evaluated.
  3. Adaptation : Requirements for the product, plans and procedures are not defined once and for all, but continuously and in detail adapted. Scrum does not reduce the complexity of the task, but structures it into smaller and less complex components, the increments .

The aim is the fast and inexpensive development of high-quality products according to a formulated vision . Implementation of the company in the finished product is not made by the preparation of detailed possible of burdens and functional specifications . In Scrum, the requirements are formulated in the form of properties from the user's point of view. The list of these requirements is the Product Backlog . These requirements are implemented piece by piece in one to four week long intervals , so-called sprints . At the end of a sprint in Scrum there is the delivery of a finished sub-product (the product increment ). The product increment should be in a state that it can be delivered to the customer ( potentially shippable product ). Following the cycle, the product, requirements and procedure are checked and further developed in the next sprint.

Scrum is designed for teams with a size of three to nine developers. Larger projects require a more extensive framework that organizes the coordination of several teams. If this coordination follows the same principles as Scrum, then one speaks of Scaled Agile Frameworks .

roll

The Scrum Framework knows three roles: Product Owner , Development Team and Scrum Master . The entirety of these roles is known as the Scrum Team. A scrum team comes into contact with those involved, the so-called stakeholders . Progress and interim results are transparent for all stakeholders. Stakeholders are allowed to listen to most events.

Various authors have argued that other roles should be included if one wants to understand Scrum as a management framework. However, since Scrum focuses on the team and is not a management framework, these roles have not been included in the Scrum framework. The three roles have proven to be sufficient for organizing a team. There are special frameworks such as the Scaled Agile Framework or Large Scale Scrum for the organization of larger units and several teams. These frameworks define additional roles that are required in large agile development organizations.

Product owner

The Product Owner is responsible for the properties and the economic success of the product. He designs the product with the aim of maximizing its benefits. The benefit could, for example, be based on the company's turnover. He creates, prioritizes and explains the product features to be developed, and he judges which features have been completed at the end of a sprint. He's a person, not a committee. He alone is responsible for the decision about the product, its properties and the order of implementation. In this way, it balances properties, delivery times and costs.

The Product Owner uses the Product Backlog to determine the product properties . In cooperation with the development team and the stakeholders, he enters the requirements for the product. The Product Owner arranges, details and updates the Product Backlog regularly in the Product Backlog Refinement .

As the person responsible for the product, the product owner regularly consults with the stakeholders in order to understand their needs and wishes. In doing so, he must understand and weigh up the interests and requirements of different stakeholders.

In practice, product owners are often not given the power to make the necessary binding decisions - in contrast to the role competence that is actually provided for in Scrum. Product owners are often overloaded with external tasks.

Development team

The development team is responsible for delivering the product functionality in the order requested by the product owner. It is also responsible for compliance with the agreed quality standards. The development team organizes itself. Nobody, not even the Scrum Master, can dictate how to implement backlog entries.

A development team should be able to achieve the goal of a given sprint without major external dependencies. Therefore, an interdisciplinary composition of the development team is important, e.g. B. with architect, developer, tester, documentation expert and database expert. Good and bad results are never attributed to individual team members, but always to the development team as a unit. The ideal team member is both a specialist and a generalist so that they can help teammates achieve the common goal.

A development team consists of a minimum of three and a maximum of nine members. On the one hand, it has to be big enough to combine all of the required competencies;

Another task of a development team is to estimate the size of the entries in the product backlog (in the product backlog refinement ). In addition, the development team breaks down the entries selected for a sprint from the product backlog in sprint planning into work steps, so-called tasks, whose processing usually takes no longer than a day. The result is the sprint backlog .

Team members sometimes have difficulties accepting the interdisciplinary requirements. For example, a developer may not understand why he should also do the work of a tester. The idea behind this, however, is that a strong team can cope with the imponderables of a project much better than a collection of individual talents. If someone is unable to cope with a task, someone else can help meet the sprint goal. If someone is absent for some time, an interdisciplinary team is better able to compensate for the lack of expertise.

Scrum Master

The Scrum Master is responsible for ensuring that Scrum works as a framework. To do this, he works with the development team, but is not part of it himself. He introduces the Scrum rules, checks that they are being adhered to and takes care of eliminating disruptions and obstacles. This includes a lack of communication and cooperation as well as personal conflicts in the development team, disruptions in the cooperation between the product owner and development team and external disruptions, for example requests from the specialist department to process additional tasks during a sprint.

A Scrum Master is a serving manager towards the development team. He does not give individual team members any work instructions. He neither judges them nor disciplines them. As a coach, the Scrum Master is responsible for the process and the removal of obstacles. Different teams and situations require situational leadership from the Scrum Master .

At the beginning of a Scrum implementation, the Scrum Master is a full-time position, since the change of the processes, the growing together of the team and the learning of the roles are usually time-consuming. He trains the team in Scrum. Once Scrum is established, the Scrum Master can take on his role as a change manager. He then has the time and the necessary experience to make Scrum known in the company and to increase its acceptance.

Stakeholders

Stakeholders are roles outside of Scrum. The following roles can help to differentiate the various stakeholders and their tasks.

Customers

The product is made available to customers after completion. Depending on the situation, customers can be internal departments as well as external persons or groups. It is the job of the product owner to inspire his customers by delivering the desired product. Therefore, the product owner and customer should be in close contact for the duration of the project. Before starting the development, the product owner should gain as precise an understanding as possible of the wishes of his customers. After the first sprints, customers should have the opportunity to look at the new functionalities and give feedback on them.

user

Users are the people who use the product. A user can, but does not have to be, a customer at the same time. The role of the user is of particular importance for the Scrum Team, because only the user can assess the product from the user's perspective. Users and customers should be involved in the sprint review and product backlog refinement to test the product and provide feedback.

management

The management is responsible for ensuring that the framework conditions are right. This includes the provision of rooms and work equipment, but also general support for the chosen course. The management is responsible for protecting the Scrum team from external work requirements, finding adequate personnel and supporting the Scrum Master in removing obstacles.

sprint

A sprint is a section of work in which an increment of product functionality is implemented. It begins with a sprint planning and ends with a sprint review and retrospective. Sprints follow one another immediately. Changes that affect the sprint goal are not allowed during a sprint.

A sprint has a time window of one to four weeks. All sprints should ideally have the same length to give the project a rhythm. A sprint is never extended - it ends when the time is up.

A sprint can be terminated prematurely by the product owner if the sprint target is no longer to be achieved, for example because the targets set by stakeholders or general market conditions change. In this case, the current sprint ends with a sprint retrospective and the new sprint begins normally with sprint planning. The Scrum Guide describes sprint interruptions as resource-intensive and unusual.

Events

The scrum process

In Scrum one speaks of events instead of meetings to make it clear that it is work. All Scrum events have fixed time windows (time boxes ) that should not be exceeded.

Sprint planning

Two questions are answered in sprint planning:

  • What can be developed in the coming sprint?
  • How will the work be done in the upcoming sprint?

Sprint planning is therefore often divided into two parts. In total, it lasts a maximum of 2 hours per sprint week, for example a maximum of eight hours for a 4-week sprint.

Part 1: Determining the What

The product owner presents the product properties recorded in the product backlog to the development team in the previously prioritized order. The Product Backlog should have been prepared in the Product Backlog Refinement beforehand in the Sprint so that it is ordered, filled and the entries for the next Sprint are estimated.

In the first part of the planning, the entire Scrum team works on developing a common understanding of the work to be done in the sprint. The properties and the acceptance criteria are discussed, for example the usability . In addition, the product owner agrees with the development team on the criteria that will decide at the end of the sprint whether the new functionality is ready or not (see definition of done ). The goal is to complete a deliverable product: a product increment that is sufficiently tested and integrated to be released to the user.

The development team then predicts the number of product backlog entries it can deliver in the next sprint. The decision as to how many entries will be implemented in the next sprint lies solely with the team, while the decision on the order lies solely with the product owner. Therefore, both must work together constructively. The Scrum Team formulates a sprint goal from the selected product backlog entries.

The original description of Scrum used the term commitment instead of forecast; this was adapted because it often led to undesirable developments at the expense of quality.

Part 2: Determining the How

In the second part of the sprint planning, the development team plans in detail which tasks are necessary to achieve the sprint goal and to deliver the forecast product backlog entries. The development team does this planning, whereby the product owner should be within reach for questions. Often small groups are formed to answer the how-question, in which various aspects such as B. Architecture, data elements and interfaces are clarified.

The result is the sprint backlog : the detailed plan for the next sprint. It contains the product backlog entries planned for the sprint and the tasks for their implementation. A task board is often used as a technique for this.

Daily Scrum

At the beginning of each working day, the development team meets for a max. 15-minute Daily Scrum, in which the Scrum Master and Product Owner are often present, but not actively involved, if they do not work on backlog elements themselves. The purpose of the Daily Scrum is to exchange information. No problems are solved in the Daily Scrum - it is more about getting an overview of the current status of work. In addition, it has been proven that each team member uses the task board to say what they have achieved since the last Daily Scrum, what they want to achieve by the next Daily Scrum, and what is in the way.

With Daily Scrum it can become obvious that a task is taking longer than planned to complete. Then it makes sense to split the task into smaller tasks, which can then be taken over by other members of the development team.

If questions arise during the Daily Scrum that cannot be answered within the strict 15-minute time limit, they are either noted down and given to the Scrum Master, or their answers are postponed to a later meeting, often immediately afterwards.

Sprint Review

The sprint review is at the end of the sprint. Here the scrum team checks the increment in order to adjust the product backlog if necessary. The development team presents its results and it is checked whether the goal set at the beginning has been achieved. The scrum team and stakeholders discuss the results and what to do next.

In the sprint review, the participation of customers and users is important, as they can use and validate the finished functionality of the increment . This results in important feedback for further product design. It can even happen that the functionality meets all acceptance criteria and is nevertheless unusable from the perspective of the user, for example if a button has been placed in a location that is difficult to find. A lively dialogue often arises during the review, in which those present come up with new functionalities.

The result of the sprint review is the stakeholder feedback noted by the product owner. This is necessary information for the further design of the product backlog in the next product backlog refinement .

It is the job of the product owner to examine the developed functionalities. Based on the conditions specified in Sprint Planning 1, he decides whether or not they can be accepted. He shouldn't make any compromises: A team has missed its goal even if it delivers an “almost finished” but not yet tested functionality. In this case, the unfinished user stories are returned to the product backlog and are re-prioritized by the product owner. However, the acceptance is not the primary subject of the Sprint Review, which is primarily about stakeholder feedback. The decrease in the functionalities of the product increment is therefore often implemented as part of the sprint.

The sprint review lasts a maximum of 1 hour per sprint week.

Sprint retrospective

The sprint retrospective is at the end of a sprint. The Scrum Team reviews its previous way of working in order to make it more efficient and effective in the future. The Scrum Master supports the Scrum Team in finding good practices and improvements that will be implemented in the next Sprint. The retrospective is a joint event of the Scrum Team.

The team should be able to review its working methods openly and honestly. To this end, criticism and unpleasant truths must be able to be expressed openly. That also includes feelings and sensations. The retrospective should therefore take place in a protected space. Stakeholders are only allowed to join by invitation. Five phases have proven effective as a structure for the sprint retrospective .

The improvement measures are documented and planned. There are different techniques for doing this. Some teams use their own list of obstacles and improvement measures (the impediment backlog ), while other teams add obstacles and the corresponding tasks to the sprint backlog.

The sprint retrospective lasts a maximum of 45 minutes per sprint week, i.e. a maximum of three hours for a four-week sprint.

Artifacts

Product backlog

The Product Backlog is an orderly listing of the requirements for the product. The Product Backlog is dynamic and is constantly being developed. All work that the development team does must originate in the product backlog. The product owner is responsible for maintaining the product backlog. He is responsible for the order and prioritization of the entries.

The Product Backlog is not complete and does not make this claim. At the beginning of a project it contains the known and best understood requirements. The entries are prioritized based on aspects such as economic benefit, risk and necessity. Entries with the highest priority are implemented first in the sprint. The risk of a requirement can be determined by analyzing its dependencies on other requirements. These dependencies are also referred to as traceability (traceability requirements English) refers to and in the mold, which manages the product backlog (z. B. IssueTracker ) detected as a byproduct.

The requirements in the product backlog should not be technical, but functional and user-oriented. One way to support this point of view is to formulate the product features as user stories . The properties desired for each user story were summarized by Bill Wake to the acronym INVEST. It is:

  • I ndependent - independent. If possible, it should not depend on other user stories.
  • N egotiable - negotiable. It should not specify implementation details.
  • V aluable - useful. Their implementation increases the practical value of the product for the end customer.
  • E stimable - appreciable. It must be possible to estimate the cost of implementation.
  • S mall - small. The effort for the implementation should be manageable. A few working days, at most a few weeks, are desirable.
  • T estable - verifiable. Its successful implementation should be able to be checked against objective criteria.

Product backlog refinement

Product Backlog Refinement (previously also known as Backlog Grooming ) is an ongoing process in which the Product Owner and the development team work together to further develop the Product Backlog. These include:

  • Order the entries
  • Deleting entries that are no longer important
  • Adding new entries
  • Detailing entries
  • Merging entries
  • Estimating entries
  • Planning of releases

Stakeholders can provide valuable information for the design of the product and the product backlog by explaining to the Scrum Team how they want functionality in everyday use. That is why there are usually product backlog refinement meetings with selected stakeholders.

The product backlog refinement should not take more than 10% of the time of the development team .

Sprint backlog

The sprint backlog is the current schedule of tasks to be completed for a sprint. It comprises the product backlog entries that were selected for the sprint and the tasks required for this (e.g. development, testing, documentation). The sprint backlog is continuously updated by the team members after a (sub) task has been completed. This provides an overview of the current processing status. A task board is often used to make it visible to everyone .

Product increment

The increment is the sum of all product backlog entries completed during the current and all previous sprints. At the end of a sprint, the new increment must be in a usable state and correspond to the definition of done .

Additional requirements

Transparency of progress

At the core of Scrum is transparency about the progress of the product and the sprint - inside and outside the team. While the product increment makes progress most clearly visible, other techniques for progress transparency are necessary. At the core of Scrum, no specific technology is specified for the transparency of progress. Burndown graphics are typically used for this .

Definition of done

The Definition of Done (DoD) is a common understanding of the Scrum Team under which conditions a work can be designated as finished. It usually contains quality criteria, restrictions and general non-functional requirements. The definition of done evolves as the Scrum Team becomes more experienced. It then contains stricter criteria for higher quality.

This includes writing comments, unit tests and design documents, for example. The DoD is determined by those involved at the beginning of a project and is adapted in the course of development. The DoD helps to determine the number and scope of the tasks at the beginning of a sprint. Not all DoD events have to apply to every user story. At the end of the sprint, the DoD, in addition to the acceptance criteria of each product backlog entry, is used to decide whether a product backlog entry is accepted as finished. The team is responsible for compliance with the DoD criteria.

Definition of Ready

The Definition of Ready (DOR) follows the approach of the Definition of Done . It is intended to ensure that an entry in the product backlog can be implemented by the team, i.e. that all necessary preconditions and inputs are available, for example stable and approved interface documents (ICDs). In addition, there must be a common understanding of the content of the entry. The product owner is responsible for compliance with the DOR. Only entries that are ready can be included in a sprint.

Complementary techniques

The following techniques are commonly used in conjunction with Scrum. These techniques are not at the core of Scrum and there are several alternatives to all techniques.

User story

User stories are a technique of describing requirements from a user's perspective using everyday language. In Scrum, user stories are used to formulate the product backlog entries. A user story describes which product features the user wants and why.

User stories generally follow this pattern:

As a USER, I want to USE FUNCTION or PROPERTY.

For a project to develop an urban electric bike, a user story could be as follows:

As a 30-year-old businesswoman, I want to have to pedal very little on the way to work so that I don't arrive at the company sweaty.

It is the job of the product owner and the team to clarify in the product backlog refinement what exactly is meant and what the acceptance criteria should be. For example, it could be agreed that up to an incline of a maximum of 20 percent, the electric drive must be so powerful that the driver does not have to contribute more than 50 watts by pedaling. In addition, the development team has to clarify with the product owner whether this user story can even be done in a sprint or whether it has to be broken down into smaller stories. As soon as a user story is rewritten or additional information is added, these changes are also recorded in the product backlog.

Questions about the how, i.e. about the technical implementation of a user story, belong in sprint planning and are not recorded in the product backlog, but in the task board with the help of the individual tasks.

Task board

The task board is a technique for visualizing the sprint backlog . This shows at any time which entries have been selected from the product backlog for the sprint, which tasks need to be processed, and the processing status of these tasks. The task board is a Kanban board .

The task board typically consists of four columns. In the first column Requirements , the entries from the Product Backlog are entered that the development team has selected for this sprint - in the order prioritized by the Product Owner. The three other columns contain the tasks or tasks that are necessary to implement the respective requirement, in their respective processing status. The second column contains all tasks still to be done, the next column those in progress and the last column all completed.

In the Daily Scrum , each member of the development team uses the task board to explain which task they were working on the day before and whether they were completed. Tasks that could not be completed on a day or where obstacles prevent progress are marked. In this case, the tasks to remove the obstacle should be included in the task board. In this way, obstacles can be identified quickly and the removal measures made transparent.

Planning poker

Planning poker cards

Scrum does not prescribe a specific method of estimating effort. With a good estimation method, the participants should initially estimate without being influenced by the other participants. On the other hand, the method should lead to an accepted and valid result in a reasonable time. Planning poker has been a common method in Scrum and generally in agile projects since around 2005. The English name Planning Poker is a protected trade name of Mountain Goat Software.

Each participant receives a set of playing cards. These are printed with degrees of difficulty or story points, for example in the system:

  • trivial - easy - medium - difficult - very difficult - extremely difficult
  • 1, 2, 3, 5, 8, 13, 21, ... these Fibonacci numbers are often chosen to cope with the increasing uncertainty in estimating more difficult tasks. The adjacent photo of planning poker cards shows that some of the values ​​have been rounded.

The planning game runs as follows:

  1. The product owner presents the user story, which is to be appreciated.
  2. The team clarifies its questions about the story in the discussion with the product owner.
  3. Each team member chooses a card that they think corresponds to the difficulty of the story.
  4. All chosen cards are revealed at the same time.
  5. The participants with the lowest and highest ratings explain their motivations.
  6. The process is repeated until consensus is reached.
  7. The game is repeated until all user stories are estimated.

If there are a large number of user stories, it is advisable to agree a time limit for each story and to monitor each of these with an hourglass or stopwatch. If the time has expired without the story being able to be estimated, then this is an indication that the description is not easy to understand and should be rewritten.

Impediment backlog

The Impediment Backlog is a technique with which the Scrum Master collects all work disabilities publicly. It is a list of obstacles, tasks to solve and their current status. Another technique is to maintain disabilities and the removal measures on the task board .

Burn down chart

Example of a sprint burndown chart

The burn-down chart is used to visualize work that has already been done and work still to be done. The burn-down chart is available in two versions:

  • As a sprint burndown, it is used to track sprint progress.
  • As a release burndown, it is used to track product progress over several sprints.

In the sprint burndown, the time course in days is plotted on the horizontal axis and the number of tasks to be completed on the vertical axis. This results in a line of open tasks, which ideally hits the zero line at the end of the sprint. With the sprint burndown it is possible to better estimate the achievement of the sprint goal. The development team updates the sprint burndown in the Daily Scrum .

Alternatively, instead of the number of tasks, the sum of the estimated efforts for each individual task can be entered for the sprint burndown. However, this requires an estimate of the remaining effort for all tasks, so that this variant requires more effort. Since the accuracy is only slightly better for tasks with an effort of a maximum of one day, counting the tasks has become established for many teams.

In the case of the release burndown, the time course in sprints is plotted on the horizontal axis and the number of product backlog entries still to be completed, for example in story points, on the vertical axis. If the scope of the Product Backlog changes, this is entered below the horizontal axis. With each sprint, the product owner updates the release burndown. With the help of the release burndown, the product owner can determine the scope and delivery date of the current release.

Five phases of a retrospective

Five phases have proven effective as the structure of a sprint retrospective :

  1. First, the conditions for an open atmosphere are created. Participants should feel comfortable discussing open points. The assumption is that everyone has done the best possible job he or she could, regardless of which open points are identified.
  2. Second, information is collected. Often this is done by looking back and determining what went well and what didn't.
  3. In the third step, knowledge is gained. At this stage, teams usually clarify why things happened so that not only symptoms can be cured, but the real causes can be identified.
  4. Fourth, you decide what to do. This includes agreements on sensible and realistic steps to be implemented in the next sprint.
  5. Finally, the retrospective will be concluded.

There are a number of possible approaches to designing the five steps.

Adaptations of Scrum

Although the Scrum Guide prescribes the essential elements of Scrum, many companies seem to deviate significantly from it. The least variation can be found in the sprints and sprint length, the meetings, the team size and in requirements engineering. The companies are most likely to vary in their effort estimate and quality assurance.

Limits and disadvantages of Scrum

No guarantee of success

Scrum cannot guarantee success any more than other processes and procedural models.

Use of knowledge gained

When using Scrum, you have to be prepared for the fact that the original assessments are permanently exceeded or undercut. From the first day on, Scrum shows deviations from the target state. Whether Scrum leads to products being developed quickly, well, cheaply or of high quality depends on how the Scrum team applies the knowledge gained. According to Schwaber, a “team of idiots” can also work according to Scrum. At the end of each sprint, the team reliably delivers product increments, holds all meetings, and distributes the roles according to Scrum. But if the scrum team doesn't use the results to work differently and make adjustments, the product won't be better or finished sooner.

Role conflicts

The self-organization in the development team implies that hierarchies are called into question. Members who are not willing to give up their previous position within the development team can therefore create conflicts. Scrum requires that all team members can work on a variety of tasks in a sprint. Someone who sees himself exclusively as a tester, programmer or architect does not fit perfectly into a Scrum development team. A good team can take this into account and compensate for the disadvantages; such people can be difficult for a less experienced team.

Legal considerations

The use of Scrum may be limited within the framework of contracts for work and services and against the background of the Product Liability Act . There is greater uncertainty about the service to be provided and its acceptance criteria than with traditional approaches. In the event of disputes, this can mean that no clear statement can be made about the fulfillment of the contract. In the specialist literature, suggestions are made on how work contracts for Scrum projects should be structured.

Certification

2003 was the year in which the first certified Scrum Masters were trained by Ken Schwaber. Several Scrum certifications compete in the market today. In addition to Scrum-focused providers, there are also agile extensions and adaptations of the established project management providers. The certifications have different costs, requirements and content. The best known include ScrumAlliance, Scrum.org and Scrum Inc., which view the Scrum Guide by Schwaber and Sutherland as a common and central standard.

ScrumAlliance Scrum.org Scrum Inc.
founder Ken Schwaber and Mike Cohn Ken Schwaber Jeff Sutherland
founding year 2001 (certifications since 2003) 2009 2006 (certifications since 2019)
offer Certified ...
  • Scrum Master
  • Scrum Product Owner
  • Etc.
 Professional...
  • Scrum Master
  • Scrum Product Owner
  • Etc.
 Licensed ...
  • Scrum Master
  • Scrum Product Owner
  • Etc.
Offer form Coach accompaniment Self-study Coach accompaniment
Validity period 2 years unlimited 1 year
Certifications

1.2 million (2020)

0.4 million (2020)

?

Tools

There are various tools such as Agilo for Scrum , Redmine (various plugins available), OpenProject , Jira , or Team Foundation Server , which are designed to facilitate the introduction of Scrum and the processes involved.

literature

  • Ken Schwaber , Mike Beedle : Agile Software Development with Scrum . Prentice Hall, Upper Saddle River 2002, ISBN 978-3-86645-643-3 .
  • Ken Schwaber : Agile project management with Scrum . Microsoft Press, Redmond 2007, ISBN 978-3-86645-631-0 (English: Agile Project Management with Scrum .).
  • Ken Schwaber : Scrum in the company . Microsoft Press, Redmond 2008, ISBN 978-3-86645-643-3 (English: The Enterprise and Scrum .).
  • Roman Pichler: Scrum: Using agile project management successfully . dpunkt.verlag, Heidelberg 2008, ISBN 978-3-89864-478-5 .
  • Holger Koschek: Stories from Scrum: From sprints, retrospectives and agile values . dpunkt.verlag, Heidelberg 2009, ISBN 978-3-89864-640-6 .
  • Jeff Sutherland , Rini van Solingen, Eelco Rustenberg: The Power of Scrum . North Charleston 2011, ISBN 978-1-4635-7806-0 .
  • Roman Pichler, Stefan Roock: Agile development practices with Scrum . dpunkt.verlag, Heidelberg 2011, ISBN 978-3-89864-719-9 .
  • Boris Gloger , André Häusling: Successful with Scrum: Influencing factor personnel management . Hanser Verlag, Munich 2011, ISBN 978-3-89864-719-9 .
  • Sven Röpstorff, Robert Wiechmann: Scrum in practice: experiences, problem areas and success factors . dpunkt.verlag, Heidelberg 2012, ISBN 978-3-89864-792-2 .
  • Ken Schwaber , Jeff Sutherland : Software in 30 days: How managers use Scrum to create competitive advantages for their companies . dpunkt.verlag, Heidelberg 2014, ISBN 978-3-86490-074-7 (English: Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust .).
  • Kenneth S. Rubin: Essential Scrum: Comprehensive Scrum knowledge from practice . mitp, 2014, ISBN 978-3-8266-9047-1 (English: Essential Scrum: A Practical Guide to the Most Popular Agile Process .).
  • Roman Pichler: Agile product management with Scrum . 2nd edition (1st edition 2012). dpunkt.verlag, Heidelberg 2014, ISBN 978-3-86490-142-3 (English: Agile Product Management with Scrum .).
  • Jeff Sutherland , JJ Sutherland: The Scrum Revolution: Breakthrough Management of the Most Successful Companies . Campus Verlag, Frankfurt 2015, ISBN 978-3-593-39992-8 (English: Scrum: The Art of Doing Twice the Work in Half the Time .).
  • Boris Gloger : Scrum : Developing products reliably and quickly . 5th edition (1st edition 2008). Hanser Verlag, Munich 2016, ISBN 978-3-446-44723-3 .
  • Ralf Wirdemann: Scrum with user stories . 3rd edition (1st edition 2009). Hanser Verlag, Munich 2017, ISBN 978-3-446-45052-3 .
  • Boris Gloger , Jürgen Margetich: The Scrum principle: building and designing agile organizations . 2nd edition (1st edition 2014). Schäffer-Poeschel, Stuttgart 2018, ISBN 978-3-7910-3947-3 .
  • Dominik Maximini: Scrum: Introduction to corporate practice . 2nd edition (1st edition 2013). SpringerGabler, Wiesbaden 2018, ISBN 978-3-662-56325-0 .
  • Rolf Dräther, Holger Koschek and Carsten Sahling: Scrum in a nutshell . 2nd edition (1st edition 2013). O'Reilly, 2019, ISBN 978-3-96009-094-6 .
  • Jeff Sutherland , James O. Coplien: Scrum: A Book About Collaboration . Vahlen, Munich 2020, ISBN 978-3-8006-6153-4 (English: A Scrum Book: The Spirit of the Game .).

Web links

Commons : Scrum  - collection of pictures, videos and audio files

Individual evidence

  1. ↑ The State of Scrum: Benchmarks and Guidelines ( PDF ; English) - see also ibid on page 10 (of 48); Scrum Alliance , June 2013 (accessed December 25, 2014)
  2. ^ Mary Poppendieck, Tom Poppendieck: Lean Software Development: An Agile Toolkit. Addison-Wesley, Upper Saddle River 2003.
  3. ↑ Malte Foegen: The Ultimate Scrum Guide 2.0. wibas, Darmstadt 2014, pp. 50–51.
  4. ^ The New New Product Development Game. Cb.hbsp.harvard.edu, January 1, 1986.
  5. ^ I. Nonaka, H. Takeuchi: The Knowledge-Creating Company. Oxford University Press, 1995.
  6. ↑ Peter DeGrace, Leslie Hulet steel: Wicked problem, Righteous Solutions: A Catolog of Modern Engineering Paradigms. 1998.
  7. ↑ Jeff Sutherland. Retrieved October 21, 2011 .
  8. ↑ https://books.google.de/books?id=od7BDwAAQBAJ Das Scrum-Praxisbuch, p. 17
  9. ↑ https://www.scruminc.com/origins-of-scrum/
  10. ↑ https://sites.google.com/a/gertrudandcope.com/info/Publications/Patterns/Process/QPW
  11. ^ Boris Gloger: Scrum. Develop products reliably and quickly. 3. Edition. Hanser Verlag, Munich 2011, p. 19.
  12. ↑ a b How did Scrum originate? (English) - accessed on May 25, 2018.
  13. ↑ Mike Beedle. Retrieved October 21, 2011 .
  14. ↑ Ken Schwaber: Scrum in the company. Microsoft Press Germany, 2008, pp. XI-XII.
  15. ↑ 1st Annual State of Agile ™ Report to 13th Annual State of Agile ™ Report
  16. ↑ Ikujiro Nonaka, Hirotaka Takeuchi: A Theory of the Firm's Knowledge-Creation Dynamics. In: Alfred Chandler et al. (Ed.): The Dynamic Firm. The Role of Technology, Strategy, Organization, and Regions. Oxford University Press, 2008, pp. 215-216.
  17. ^ Boris Gloger: Scrum. Develop products reliably and quickly. 3. Edition. Hanser Verlag, Munich 2011, pp. 27–30.
  18. ↑ Scrum Code of Ethics
  19. ↑ The Agile Atlas - Core Scrum - Improuv (improuv.com), with reference to a 12-page PDF (≈ 120 KB); Translation from January 2013; Retrieved December 25, 2016.
  20. ↑ a b c d e f Jeff Sutherland Ken Schwaber: The Scrum Guide . (PDF) scrum.org, November 2017, accessed on September 24, 2017 .
  21. ↑ Malte Foegen: The Ultimate Scrum Guide . wibas, Darmstadt 2014, pp. 112–113.
  22. ^ Boris Gloger: Scrum. Develop products reliably and quickly. 3. Edition. Hanser Verlag, Munich 2011, p. 12.
  23. ↑ a b Ken Schwaber, Jeff Sutherland: The Scrum Guide . P. 7.
  24. ^ Dean Leffingwell: Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development) . Addison-Wesley, Boston 2010.
  25. ↑ Craig Larman, Bas Vodde: Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, Boston 2010.
  26. ^ Scrum Alliance: Agile Atlas. ( Memento from June 12, 2014 in the Internet Archive ) V 2012.12.13, pp. 4–6.
  27. ↑ Boris Gloger, Scrum - Developing Products Reliably and Quickly, Hanser, 4th edition, 2013.
  28. ^ Dean Leffingwell: Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development). Addison-Wesley, Boston 2010.
  29. ↑ Craig Larman, Bas Vodde: Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, Boston 2010.
  30. ↑ Ken Schwaber, Jeff Sutherland: The Scrum Guide. November 2017. Retrieved on September 28, 2018, p. 6 (PDF; 582 kB).
  31. ^ Scrum Alliance: Agile Atlas. ( Memento from June 12, 2014 in the Internet Archive ) V 2012.12.13, p. 4.
  32. ^ Boris Gloger: Scrum. Develop products reliably and quickly. 3. Edition. Hanser Verlag, Munich 2011, pp. 78–87.
  33. ↑ Roman Pichler: Scrum - using agile project management successfully. d.punkt Verlag, Heidelberg 2009, pp. 10-13.
  34. ↑ Roman Pichler: Scrum - using agile project management successfully. d.punkt Verlag, Heidelberg 2009, p. 15.
  35. ^ Scrum Alliance: Agile Atlas. P. 5.
  36. ↑ Roman Pichler: Scrum - using agile project management successfully. d.punkt Verlag, Heidelberg 2009, pp. 20-23.
  37. ↑ Malte Foegen: The Ultimate Scrum Guide 2.0. wibas, 2014, pp. 62–65.
  38. ^ Boris Gloger: Scrum. Develop products reliably and quickly. 3. Edition. Hanser Verlag, Munich 2011, pp. 88–101.
  39. ^ Boris Gloger: Scrum. Develop products reliably and quickly. 3. Edition. Hanser Verlag, Munich 2011, pp. 101-103.
  40. ^ Scrum Alliance: Agile Atlas. ( Memento from June 12, 2014 in the Internet Archive ) V 2012.12.13, p. 10.
  41. ^ Boris Gloger: Scrum. Develop products reliably and quickly. 3. Edition. Hanser Verlag, Munich 2011, pp. 104–107.
  42. ↑ Ken Schwaber, Jeff Sutherland: The Scrum Guide . P. 9 f.
  43. ^ Scrum Alliance: Agile Atlas. ( Memento from June 12, 2014 in the Internet Archive ) V 2012.12.13, p. 3.
  44. ↑ Ken Schwaber, Jeff Sutherland: The Scrum Guide . P. 10.
  45. ↑ Ken Schwaber, Jeff Sutherland: The Scrum Guide . P. 9.
  46. ↑ Ken Schwaber, Jeff Sutherland: The Scrum Guide . P. 9.
  47. ^ Scrum Alliance: Agile Atlas. ( Memento from June 12, 2014 in the Internet Archive ) V 2012.12.13, pp. 7–8.
  48. ↑ Jose Luis Soria Teruel: Commitment vs. Forecast: A subtle but important change to Scrum . Retrieved January 18, 2013.
  49. ^ Roman Pichler: Scrum. Use agile project management successfully. dpunkt.verlag, Heidelberg 2009, pp. 104-107.
  50. ↑ Ken Schwaber, Jeff Sutherland: The Scrum Guide . P. 13.
  51. ^ Scrum Alliance: Agile Atlas. ( Memento from June 12, 2014 in the Internet Archive ) V 2012.12.13, pp. 10-11.
  52. ↑ Ken Schwaber, Jeff Sutherland: The Scrum Guide . P. 14.
  53. ^ Scrum Alliance: Agile Atlas. ( Memento from June 12, 2014 in the Internet Archive ) V 2012.12.13, p. 11.
  54. ↑ Rolf Dräther: Retrospectives in a nutshell . O'Reilly, Cologne 2014, p. 125.
  55. ↑ Malte Foegen: The Ultimate Scrum Guide 2.0. wibas, Darmstadt 2014, pp. 140–141.
  56. ↑ Ken Schwaber, Jeff Sutherland: The Scrum Guide . Pp. 15-16.
  57. ^ Scrum Alliance: Agile Atlas. ( Memento from June 12, 2014 in the Internet Archive ) V 2012.12.13, p. 6.
  58. ↑ Patrick Rempel, Patrick Mäder: Estimating the Implementation Risk of Requirements in Agile Software Development Projects with Traceability Metrics . In: Requirements Engineering: Foundation for Software Quality (=  Lecture Notes in Computer Science ). No. 9013 . Springer International Publishing, 2015, ISBN 978-3-319-16100-6 , pp. 81–97 , doi : 10.1007 / 978-3-319-16101-3_6 ( springer.com [accessed January 18, 2017]).
  59. ^ Bill Wake: INVEST in Good Stories, and SMART Tasks. August 17, 2003, accessed August 25, 2018 .
  60. ↑ scrumtrainings.wordpress.com: Scrum and Backlog Refinement (or Backlog Grooming)
  61. ↑ Ken Schwaber, Jeff Sutherland: The Scrum Guide . P. 16.
  62. ^ Scrum Alliance: Agile Atlas. ( Memento from June 12, 2014 in the Internet Archive ) V 2012.12.13, pp. 6-7.
  63. ↑ Malte Foegen: The Ultimate Scrum Guide 2.0. wibas, Darmstadt 2014, pp. 92–93 and 96–97.
  64. ↑ scrum-master.de
  65. ^ Scrum Alliance: Agile Atlas. ( Memento from June 12, 2014 in the Internet Archive ) V 2012.12.13, p. 9.
  66. ^ Scrum Alliance: Agile Atlas. ( Memento from June 12, 2014 in the Internet Archive ) V 2012.12.13, p. 9.
  67. ^ Scrum Alliance: Agile Atlas. ( Memento from June 12, 2014 in the Internet Archive ) V 2012.12.13, pp. 9-10.
  68. ↑ Roman Pichler: Scrum - using agile project management successfully. d.punkt Verlag, Heidelberg 2009, pp. 46–47.
  69. ↑ Malte Foegen: The Ultimate Scrum Guide 2.0. wibas, Darmstadt 2014, pp. 104–105.
  70. ↑ Roman Pichler: Scrum - using agile project management successfully. d.punkt Verlag, Heidelberg 2009, pp. 46–47.
  71. ^ Boris Gloger: Scrum. Develop products reliably and quickly. 3. Edition. Hanser Verlag, Munich 2011, pp. 167–169.
  72. ^ Mike Cohn: Agile Estimating and Planning . Prentice Hall , 2005, ISBN 0-13-147941-5 .
  73. ↑ a b c Scrum Effort Estimations - Planning Poker , The International Scrum Institute, accessed February 20, 2015.
  74. ↑ Malte Foegen: The Ultimate Scrum Guide 2.0. wibas, Darmstadt 2014, pp. 148–151.
  75. ^ Esther Derby, Diana Larsen: Agile Retrospectives: Making Good Teams Great. Pragmatic Programmers, 2006.
  76. ↑ Retromat - Suggestions and processes for (agile) retrospectives. Retrieved January 11, 2020 .
  77. ↑ elib.uni-stuttgart.de: What do practitioners vary in using scrum?
  78. ↑ Ken Schwaber: Scrum et al. (Minute 14) Retrieved August 12, 2011.
  79. ↑ Tom Arbogast, Craig Larman, Bas Vodde: Practices for Scaling Lean & Agile Development. Addison-Wesley Longman, Amsterdam 2010, ISBN 978-0-321-63640-9 , p. 499 ff. (PDF)
  80. ↑ Andreas Opelt, Boris Gloger, Wolfgang Pfarl, Ralf Mittermayr: The agile fixed price: guidelines for really successful IT project contracts . Carl Hanser Verlag, 2012, ISBN 978-3-446-43226-0 .
  81. ↑ SCRUM Usergroup Germany: Training & Certification. In: scrum-usergroup.de. Retrieved May 12, 2016 .
  82. ↑ https://www.scruminc.com/scrum-alliance-scrum-inc-scrum-org-scrum-guide/
  83. ↑ Tracy Brower: Why Agile Is The Mindset To Get Us Through The COVID Crisis: 4 Lessons From Agile For Today And The New Normal. Retrieved May 18, 2020 .
  84. ↑ Professional Scrum Certified Count. Retrieved May 18, 2020 .