Was ist Scrum?

Ein vollständiger Überblick über die Methode, Praktiken und Tools

Was ist Scrum? Scrum ist ein agiles Framework. Einige sind sogar der Meinung, dass die beiden Begriffe identisch sind. Dies ist jedoch nicht richtig. Agil ist eine Projektmanagement-Methode, bei der es darum geht, den größten Nutzen zu liefern. Sie nennt 12 Prinzipien, die Unternehmen befolgen müssen. Scrum ist ein Framework, das Teams und Unternehmen verwenden, um agile Werte in ihre täglichen Aktivitäten zu integrieren. Was ist also Scrum?

Die Scrum Methode ist ein Framework für agiles Projektmanagement. Lassen Sie uns mehr davon erzählen.

Die Geschichte von Scrum 

In den 90er Jahren fingen die Gespräche über die Verbesserung von den Arbeitsmethoden der Software-Entwicklungsteams an. Wasserfall-Projekte lieferten ständig verspätete Ergebnisse, und alles, was die Manager taten, um die Situation zu verbessern, machte sie noch schlimmer. Auf der Suche nach etwas, das funktioniert, begann Jeff Sutherland mit kleineren Teams zu arbeiten und Projekte um Iterationen herum zu organisieren. Er verstand schnell, dass diese Art der Arbeitsorganisation Transparenz, Fokus und Engagement bot, die den Wasserfall-Projekten fehlte.

Als die Teams begannen, schnell Ergebnisse zu liefern, wuchs das Interesse an dieser neuen Projektmanagementmethode. Ein Kollege von Jeffs zog die Parallele zwischen einem kleinen Software-Team, das eng zusammenarbeitete, und dem Rugby „scrummage“. So wurde der Name Scrum geboren. Und es waren Ken Schwaber und Jeff Sutherland auf der OOPSLA-Konferenz 1995, die den Prozess von Scrum offiziell der Öffentlichkeit vorstellten.

Seitdem wurde Scrum von vielen anderen verbessert und wuchs von einem Prozess zu einem voll entwickelten Framework. Und als solches wurde es zu einer der beliebtesten Arten der Anwendung von Agile. Laut dem 14. State of Agile-Bericht gaben 58% der Befragten an, dass sie Scrum zur Anwendung von Agile verwenden. Ein Teil dieser Popularität hängt zweifellos mit der Tatsache zusammen, dass Scrum recht einfach zu verstehen ist. Der Hauptgrund für die breite Anwendung ist jedoch, dass es eine Möglichkeit bietet, komplexe Probleme zu lösen und gleichzeitig produktiv und kreativ Ergebnisse von höchstmöglichem Wert zu liefern.

Die Hauptidee 

Die Scrum Methode ist einfach – das Team plant und erledigt die Arbeit in Iterationen von 1 bis 4 Wochen und liefert nach jedem Sprint einen hohen Mehrwert. Nach jedem Sprint wird dann eine Besprechung mit den Stakeholdern organisiert, um Feedback zu erhalten, und das Team kann die Vorgehensweise für den nächsten Sprint entsprechend den Kommentaren der Stakeholder anpassen. Dadurch wird es einfach, auf Veränderungen innerhalb oder außerhalb des Unternehmens zu reagieren und sich an diese anzupassen.

Mit Scrum kann das Team einfacher kommunizieren, schneller Feedback sammeln und weiter in die Richtung arbeiten, die für alle am besten geeignet ist. Diese Arbeitsweise erfordert Transparenz und Verantwortlichkeit und das Team arbeitet als eine Einheit an einem einzigen Ziel.

Scrum funktioniert am besten, wenn es in einer Teamumgebung eingesetzt wird. Daher sollten auch große Organisationen die Arbeit in autonomen Teams organisieren. Scrum kann skaliert werden, um Unternehmen unterschiedlicher Größe zu unterstützen. Mit steigender Unternehmensgröße sinkt jedoch die Scrum-Produktivität. Sie sollten sich auf ein solches Szenario vorbereiten und Ihren Teams keine Vorwürfe machen.

Wie funktioniert es? 

Um die Arbeit zu organisieren und die gewünschten Ergebnisse zu liefern, verwendet Scrum bestimmte Rollen, Werkzeuge und Praktiken. Und wenn man sie kennt, bekommt man eine genaue Vorstellung davon, wie die Arbeit in einem Scrum-Projekt aussieht. Hier sind sie also.

Die Rollen

Als erstes sollten Sie auf die Struktur Ihres Unternehmens achten. Scrum funktioniert am besten, wenn die Arbeit in kleinen Teams mit spezifischen Zielen verteilt wird. Sie sollten also Ihre Struktur überprüfen und vielleicht auch neu gestalten. Sobald die Verteilung von Teams klar ist, werden Sie auch neue Rollen zuweisen müssen. Scrum erfordert, dass in jedem Team 3 bestimmte Rollen zur Verfügung stehen.

Scrum roles
Scrum Rollen, Quelle: Scrum Alliance

Das Scrum Entwicklungsteam

Scrum ist nicht nur eine Methode, um zu entwickeln, sondern auch eine Möglichkeit Zusammenarbeit zu organisieren. Wir nennen das Team, dass die Anforderungen schließlich umsetzt das Entwicklungsteam. Dieses Team fällt Entscheidungen gemeinsam. Wenn das Team vom Product Owner die Anforderungsliste (Product Backlog) vorgelegt bekommt, entscheidet es, wie es mit den Anforderungen in der nächsten Arbeitsphase (Sprint) umgeht.

Ein Team sollte aus 7 Personen aus verschiedensten Disziplinen bestehen. Sollten mehr Mitarbeiter als 10 nötig sein, dann sollte auf kleinere Teams aufgeteilt werden. Die geringe Größe stellt sicher, dass untereinander ausreichend kommuniziert werden kann und macht die Selbstorganisation leichter.

Der Product Owner

Der Product Owner ist derjenige, der das Ziel und die Anforderung des Projektes formuliert und beim Scrum Team in Auftrag gibt. Dazu fungiert er als Schnittstelle zwischen dem Scrum Team und der Außenwelt, also Kunden, Stakeholdern und anderen Beteiligten.

Das heißt, der Product Owner ist verantwortlich dafür, dass das entstandene Produkt später beim Kunden auch gut ankommt, dass es für den Kunden attraktiv und dadurch marktfähig ist. Die Informationen, die er vom Kunden erhält, schlüsselt er in einzelne Arbeitsaufgaben auf und stellt dem Team dann das zu erreichende Ziel sowie die Schritte dorthin zur Verfügung; dafür erstellt er eine Anforderungsliste (Product Backlog).

Weiterhin fällt in seinen Verantwortungsbereich die Priorisierung der Aufgaben: Womit wird angefangen, was ist im Moment das Wichtigste? Er kann einschätzen, worauf der Kunde gerade seinen größten Schwerpunkt legt; so könnte es in der Softwareentwicklung vorrangig sein, dem Kunden einen bestimmten Teil eines Programms zügig zum Testen vorlegen zu können.

Nach Abschluss eines Sprints nimmt der Product Owner die gemachten Fortschritte ab, gibt seine Meinung dazu und holt die Rückmeldungen von Kunden und Stakeholdern dazu ein. Diesen Arbeitsschritt nennt man Sprint Review.

Der Scrum Master

Der Scrum Master moderiert den Prozess, indem er sicherstellt, dass die Kommunikation fließt und dass die verschiedenen Meeting-Formate und Strukturen auch gelebt werden. Statt Aufgaben zu organisieren und zu verteilen, stellt er die Plattform zur Verfügung, die dem Entwicklungsteam ermöglicht selbst zu entscheiden wer wann welche Aufgaben übernimmt, wie sie organisiert werden und wie viele davon in welchem Zeitraum zu schaffen sind. Bei diesen Entscheidungen steht er moderierend zur Seite.

Der Scrum Master räumt Hindernisse aus dem Weg und schützt sein Team vor Störungen von außen.

 Wenn einmal Konflikte auftreten, dann übernimmt er die Rolle des Mediators.

Hier ist ein ausführlicher Artikel, der den Unterschied zwischen einem Scrum Master und einem Projektmanager erklärt.

Die Tools

Es ist jetzt Zeit, von den Werkzeugen von Scrum zu erzählen. Scrum erfordert eine etwas andere Art und Weise der Planung und Verfolgung der Arbeit. Daher verwendet das Framework ein Scrum-Board, User Stories und Story Points, um die Arbeit des Teams zu beschreiben. Hier ist ein wenig mehr über jedes Werkzeug.

Scrum-Board 

Das Scrum-Board ist eines der wichtigsten Werkzeuge, das eine effektive Planung und Verfolgung des Fortschritts ermöglicht. Es besteht normalerweise aus 3 Teilen, die vom Product Owner oder dem Scrum-Team verwaltet werden.

Das erste Element ist das Product Backlog. Dieses wird nur vom Product Owner verwaltet und enthält alle Pläne für das Projekt in Form von priorisierten User Stories. Das Scrum-Team kann zwar auch User Stories von den Stakeholdern sammeln, aber nur der Product Owner kann sie zum Product Backlog hinzufügen. Dieses Element des Boards wird bei jedem Sprintplanning verwendet, um das Sprint-Ziel festzulegen und Aufgaben zu planen.

Das zweite Element ist das Sprint Backlog. Dies ist der Ort, den das Scrum-Team verwendet, um User Stories in konkrete Aufgaben zu unterteilen. Das Sprint Backlog wird während des Sprints geleert und dann während jeder Sprintplanning-Sitzung mit neuen Tasks wieder aufgefüllt.

Die Spalten zur Fortschrittsverfolgung sind das letzte Element des Scrum-Boards. Diese wird ebenfalls vom Scrum-Team verwaltet und hilft, den Fortschritt des Sprints zu verfolgen. Dieses Element kann nur aus zwei Teilen bestehen – Doing und Done – oder so detailliert, wie es das Team benötigt, sein, um den Fortschritt effektiv zu verfolgen. Hier sind ein paar Beispiele für Scrum-Boards.

scrum board example
Einfaches Scrum-Board: Teamhood
scrum board example
Leistungsstarkes Scrum-Board: Teamhood

What is Scrum board

Erstellen Sie Ihr eigenes Scrum-Board mit Teamhood!

Visualisieren Sie User Stories, verwenden Sie Story Points.

What is Scrum board

User Stories 

Um Pläne und Elemente zu definieren, verwendet Scrum User Stories. Diese werden von den Kunden gesammelt und definieren, wie das Endergebnis des Projekts aussehen soll. Um beim Schreiben der User Stories zu helfen, gibt es ein bestimmtes Format, das sie folgen müssen – Als …, ich will …, damit … .

Wenn der Product Owner also Informationen von Kunden und Beteiligten sammelt, schreibt er die User Stories in diesem Format auf und platziert sie entsprechend ihrer Priorität im Product Backlog. Während des Sprint-Plannings wählt das Scrum-Team die wichtigsten User Stories aus und hat dann die wichtigsten Aufgaben, die es erledigen muss.

Beim Schreiben von User Stories ist es wichtig zu beachten, dass das Scrum-Team in der Lage sein muss, diese in einem Sprint zu bewältigen. Wenn das nicht möglich ist, wird die User Story zu einem Epic. Dies teilt der Product Owner dann in kleinere User Stories auf. Lesen Sie mehr über User Stories.

user story
User Story in Teamhood

Story Points 

Story Points sind eine Einheit zur Beschreibung der Größe einer User Story. Sie repräsentieren den Entwicklungsaufwand und die Faktoren, die diesen Aufwand beeinflussen.

Es geht bei Story Points primär also nicht um die Zeit, die zur Umsetzung der User Story benötigt wird, sondern um die strukturellen Eigenschaften einer User Story. Ein erfahrenes Entwicklungsteam kann natürlich im Vergleich zu einem weniger erfahrenen Team größere User Storys in einem Sprint umsetzen, doch die Größe der Story bleibt davon unberührt. In anderen Worten: die Eigenschaften einer User Story hängen nicht von den Fähigkeiten des Teams ab. Die Schätzung einer User Story verändert sich also auch nicht, wenn anstelle eines Junior-Entwicklers ein Senior-Entwickler die Implementierung vornimmt.

Da es jedoch nicht einfach ist, alle Faktoren in einer einzigen Zahl wiederzugeben, empfiehlt es sich, immer den Aufwand zu den Faktoren zu bestimmen: Wie viel Aufwand macht es bspw., mit dem Risiko und der Ungewissheit umzugehen? Je höher der Aufwand zur Beseitigung einer Unsicherheit ist, desto höher wird die Einschätzung der Story Points. Die Kombination der Faktoren führt somit zur Story Points Schätzung – auch als Story Points Estimation bezeichnet.

Scrum Prozess

Der Scrum Prozess besteht in einer wiederkehrenden Abfolge von Sprints. Dabei ist jeder  Sprint durch fest definierte Meetings gekennzeichnet, deren Intention, Dauer und Ziele klar definiert sind.

Der Sprint 

Der Sprint ist das oberste zentrale Ordnungsprinzip im Scrum Framework. Dabei ist ein Sprint ein fest definiertes Zeitintervall, in dem das Team an der Erledigung der vereinbarten Aufgaben und der Erreichung des Sprint-Ziels arbeitet. Sprints geben sich die Klinke in die Hand. Das heißt, das Ende des einen Sprints ist der Anfang des nächsten Sprints. Die Dauer eines Sprints beträgt typischerweise 1-4 Wochen und wird in Abhängigkeit des Produktes / Projektes festgelegt. 

Die Sprintdauer ist fix, d.h. alle Sprints haben die gleiche Dauer. Das gilt solange, bis man möglicherweise feststellt, dass eine andere Sprintdauer angemessener wäre. Dann ändert man die Sprintdauer und bleibt dabei.  

Sprints dauern max. vier Wochen. Der relativ kurze Zyklus von vier Wochen ist der Einsicht geschuldet, dass mit zunehmender Länge eines Zyklus die Qualität der Planung sinkt.

4 Schlüsselereignisse finden bei jedem Sprint statt, um ihn effektiv zu gestalten.

what is scrum
Scrum Prozess, Quelle: ScrumThing

I. Sprint Planning 

Jeder Sprint startet mit einem gemeinsamen Planning, an dem das gesamte Scrum Team (PO, Projektteam, Scrum Master) teilnimmt. Während des Plannings werden anstehende Aufgaben diskutiert und der erwartete Aufwand geschätzt. Mit der Schätzung über den erwarteten Aufwand wird der PO befähigt, um auf Basis des erwarteten Nutzens und der Kosten eine Entscheidung bzgl. der Priorisierung zu treffen.

Das umsetzende Team committet sich auf die Aufgaben, übernimmt die priorisierten Aufgaben in sein Sprint Backlog und der PO formuliert abschließend ein Sprint Ziel. Bei einem vierwöchigen Sprint werden für ein Planning 8 Stunden angesetzt.

II. Daily Scrum 

Das Daily ist eine tägliche Synchronisation des umsetzenden Teams. Da die Dauer auf 15 Minuten begrenzt ist, findet es oft im Stehen statt. Deswegen wird es mitunter auch “Stand Up” genannt. Dabei haben das Stehen und die enge Timebox einen ganz einfachen Hintergrund. Denn statt sich in epischer Breite auszulassen, ist jedes Teammitglied eingeladen ein kurzes Update zu geben, um sich mit den Kollegen zu synchronisieren.

Wo stehe ich gerade, brauche ich Hilfe, habe ich sonstige Fragen? Sollte sich daraus weiterer Gesprächsbedarf ergeben, finden im Anschluss an das Daily weiterführende Gespräche statt, anstatt das gesamte Team während des Dailys damit zu behelligen. Das Daily ist ein Meeting das Projektteams, das jeden Tag zu gleicher Zeit am gleichen Ort stattfindet. Das heißt, der Scrum Master und der Product Owner nehmen nur optional teil. 

III. Sprint Review 

Zum Ende des Sprints präsentiert das Projekt- bzw. Produktteam die Arbeitsergebnisse des Sprints. Zu der Review werden neben dem Product Owner, vor allem interessierte Stakeholder und auch ausgewählte Kunden eingeladen. Zum einen bietet die Review dem Projekt- bzw. Produktteam eine Bühne für das was es im zurückliegenden Sprint geschafft hat. Zum anderen erhalten Stakeholder und eingeladene Personen die Möglichkeit Feedback zu geben und Fragen zu stellen, um damit auch auf künftige Planungen Einfluss zu nehmen.

Die Entscheidung, was davon wie priorisiert wird, obliegt jedoch alleine dem Product Owner. Das heißt, die Review ist keine Abnahme und auch ausdrücklich nicht mit einem Lenkungsausschuss zu vergleichen. Denn hier präsentiert ein autonomes Team, das auf Basis einer gemeinsamen Planung mit dem Product Owner sein bestmögliches getan hat. Nicht fertiggestellte Arbeitspakete und Aufgaben wandern direkt in das nächste Planning. 

IV. Sprint Retrospective 

Schließlich endet der Sprint mit einer Retrospektive des Scrum Teams. Dazu treffen sich das Projektteam, der Product Owner und der Scrum Master, um die Zusammenarbeit zu reflektieren und basierend auf diesen Einsichten Vereinbarungen für künftige Sprints zu treffen. Das heißt, in der Retrospektive geht es ausschließlich um den Arbeitsprozess, gar nicht um Inhalte bzw. Arbeitsergebnisse. 

Dabei sind Retrospektiven dann besonders wirksam, wenn Teilnehmer den Wunsch nach ständiger Verbesserung und eine gesunde Portion Selbstreflexion mitbringen. In der japanischen Lean Philosophie wird diese Haltung mit den Prinzipien Kaizen und Hansei bestens beschrieben. Die Retrospektive schließt mit konkreten Vereinbarungen, die im nächsten Sprint umgesetzt werden und unter Umständen auch einen eigenen Eintrag im Sprint Backlog erhalten.

Häufige Missverständnisse

Hier sind einige der häufigsten Missverständnisse in Bezug auf den Scrum Prozess:

1. Scrum Master ist der Boss

Das Wort „Master“ klingt zwar grandios, aber der Scrum Master ist nicht da, um Befehle zu geben. Die Rolle des Scrum-Masters besteht darin, dem Team zu helfen, die Scrum Praktiken zu folgen. Scrum Master soll den Scrum-Prozess erleichtern und die Unternehmenskultur verändern.

Der Scrum-Master sorgt dafür, dass der Scrum-Prozess funktioniert.

2. Daily Meetings sind nur zum Check-In da

Es wurde nun eindeutig betont, dass es mehrere verschiedene Möglichkeiten gibt das Daily Scrum zu leiten, solange das Entwicklerteam sich auf den Fortschritt zur Erreichung des Sprintziels konzentriert.

Das kann getan werden, indem man die Arbeit und die Ergebnisse, die seit dem letzten Daily Scrum erledigt wurde, genau inspiziert. Zudem muss die Arbeit für die nächsten 24 Stunden abgestimmt werden, um die Zusammenarbeit und die Performance zu optimieren. Das „3 Fragen“-Format ist auch lediglich ein Beispiel, keine Vorschrift.

3. Am Ende eines jeden Sprints wird ein Produktinkrement geliefert und veröffentlicht

Das Entwickler-Team kann jederzeit und so häufig wie gewünscht im Laufe eines Sprints Auslieferungen vornehmen, solange mindestens ein potentielles Produktinkrement pro Sprint freigegeben wird. Wie im Abschnitt „Sprint“ beschrieben, können Veröffentlichungen ebenfalls jederzeit und so oft wie gewünscht durchgeführt werden. Scrum verlangt nicht einmal, dass jeden Sprint eine Veröffentlichung durchgeführt werden muss. Ausschließlich der Product Owner entscheidet, wann veröffentlicht wird. Und das kann theoretisch auch mehrmals während eines Sprints sein.

4. Der Sprint-Review für einen einmonatigen Sprint dauert vier Stunden

Wo vorher im Scrum Guide stand:
„Es ist ein vierstündiges Meeting für einen 1-Monat-Sprint.“

Steht jetzt im Scrum Guide geschrieben:
„Es ist zumeist ein vierstündiges Meeting für einen 1-Monat-Sprint.“

Dies betont, dass es in Ordnung ist, die Timebox bei Gelegenheit zu verkleinern. Das gilt zudem auch für die Sprint Retrospektive. Also wenn Sie fertig sind, bevor die Timebox abläuft, können Sie das Meeting auch eher beenden.

5.  Scrum wird nur in der IT angewandt

Auch wenn der Scrum Guide keine Wörter wie „IT“ oder „Software“ beinhaltet, hört man trotzdem oft, dass Scrum nur für die IT-Branche gedacht ist. Ironischerweise beinhaltet die neueste Version des Scrum Guide jetzt sogar das Wort „Software“, aber nur in dem Zusammenhang, dass Scrum nicht nur auf die Softwareentwicklung limitiert ist. Das neue Kapitel „Uses of Scrum“ erklärt, dass Scrum zudem auch für Produkte, Dienstleistungen und das Management der einzelnen Organisationen genutzt werden kann. Scrum ist ein Framework, in welchem komplexe Probleme angesprochen werden können, und ja, die Softwareentwicklung neigt ebenfalls dazu komplex zu sein.

6. Der Scrum Master ist nur ein Team Coach

Die Rolle des Scrum Master wird oft missverstanden. Glücklicherweise beschreibt der aktuelle Scrum Guide ausführlicher, welche Verantwortungen der Scrum Master trägt: „Die Aufgabe des Scrum Masters ist es, Scrum so zu fördern und zu unterstützen, wie es im Scrum Guide niedergeschrieben ist. Scrum Master machen das, indem sie allen dabei helfen, die Scrum Theorien, Praktiken, Regeln und Werte zu verstehen.“

Ein Scrum Team operiert in einem organisatorischen Umfeld. Dieses beeinflusst, wie effektiv das Scrum Team sein kann. Die anderen Personen zu coachen und das Umfeld um das Scrum Team zu optimieren ist ausschlaggebend, um mit Scrum erfolgreich zu sein. Der Scrum Master kann auch als Change Agent für Agilität und Scrum im gesamten Unternehmen angesehen werden, der kontinuierlich Hindernisse beseitigt.

Zusammenfassung

Scrum ist ein großartiges Framework, um neue Ideen zu testen. Man kann auch sofort verstehen, ob sie auf lange Sicht funktionieren werden. Nach ein paar Iterationen haben Teams bereits messbare Ergebnisse, die sie den Stakeholdern liefern können. Scrum ist eine gute Wahl für Teams, die Projekte unter sich ständig ändernden Umständen verwalten müssen. Und ehrlich gesagt, das sind die meisten von uns.

Im Vergleich zu anderen agilen Frameworks ist Scrum das verständlichste. Allerdings sollten Sie darauf achten, dass die Implementierung von Scrum nicht so einfach ist, wie Sie vielleicht denken. Wenn es Sie interessiert, wie Scrum im Vergleich zu anderen agilen Frameworks aussieht, hier ist Scrum vs Kanban vs Scrumban.  

Und wenn Sie Scrum in einem größeren Unternehmen testen wollen, hier ist ein Überblick über der Scrum of Scrums.

What is Scrum board

Beginnen Sie Ihr Scrum Abenteur jetzt!

Erstellen Sie ein kostenloses Scrum-Board und beginnen Sie in 5 Minuten, Ihren Fortschritt zu verfolgen.

What is Scrum board

Resources

Wissensbasis

User Stories

Obwohl der Begriff „User Story“ im Scrum Guide nicht auftaucht, nutzen agile Arbeitstechniken ihn häufig. User Stories stehen im Backlog neben Epics und Tasks, Qualitätsanforderungen, Fehlern und Verbesserungen.

User Stories bestehen aus wenigen, leicht verständlichen Sätzen. Sie sind kurz, aus Kundensicht jedoch spezifisch und detailliert.

As a I want to, so that.

Scrum of Scrums (SoS)

Das Scrum of Scrums bezeichnet ein regelmäßiges Treffen von Vertretern einzelner Scrum-Teams. Es dient dem Zweck, sich gegenseitig über den Status quo der einzelnen Teams, über anstehende Tätigkeiten und mögliche Hindernisse bei der Entwicklung auszutauschen. Ziel des Scrum of Scrums ist es, die Arbeit der verschiedenen Scrum-Teams zu synchronisieren und Entwicklungen von Teams zu identifizieren, die andere Teams bei der Umsetzung ihrer Anforderungen beeinflussen. Es ist somit eine Technik zur Skalierung von Scrum und für viele größere Unternehmen relevant.

Scrum of Scrums

Scrumban

Scrumban ist ein aus Scrum und Kanban gebildetes Kunstwort und beschreibt einen Methodenmix der beiden mit Scrum-Events, Kanban-Visualisierung, WIP-Grenzen, Pull-System und kontinuierlichem Fluss. Diese Kombination ist besonders für solche Unternehmen nützlich, die von Scrum auf Kanban umstellen oder Agile-Methoden ausprobieren möchten, aber besonderen Wert auf einen Pull-Workflow legen.

Scrumban

Scrum vs Kanban vs Scrumban

Teams, die Kanban, Scrum, Scrumban oder eine andere agile Technik verwenden, erhalten eine flexible Transparenz ihrer Prozesse und Details.

Um Ihnen eine Vorstellung davon zu vermitteln, wie sich diese drei Praktiken im Prinzip unterscheiden, finden Sie hier einen Vergleich der drei heute am häufigsten verwendeten agilen Lösungen – Scrum, Kanban und Scrumban.

Scrum Spickzettel

Scrum-Spickzettel. Die wichtigsten Begriffe und Terminologien für Sie.

Teamhood uses cookies to improve your experience, personalize content and ads, to provide social media features and to analyze our website‘s traffic. By agreeing you accept the use of Cookies in accordance with our Cookie Policy.