Anzeige
Diese Webseite verwendet Affiliate-Links. Erfolgt eine Bestellung oder ein Kauf über diese Links, erhält trusted eine Provision vom jeweiligen Anbieter. Das ermöglicht es uns, Ihnen unseren Service und unsere Inhalte kostenlos zur Verfügung zu stellen. Die Provision hat keinen Einfluss auf unsere Bewertung oder unser Ranking! Wir bewerten stets neutral und unabhängig.
Projektmanagement

Scrum-Methode: Definition, Rollen & Tipps im großen Guide

Du interessierst dich für Scrum und agiles Projektmanagement? Mein ultimativer Scrum-Guide zeigt dir, wie Scrum funktioniert, wie du Scrum Schritt für Schritt in deinem Team einführst und gibt dir nützliche und praktische Tipps. Mach dein Team jetzt agil!

Klickst Du auf eine Emp­feh­lung mit , unterstützt das unsere Arbeit. trusted bekommt dann ggf. eine Vergütung. Emp­feh­lungen geben wir immer nur redaktionell unabhängig.Mehr Infos.

Die besten Scrum-Tools

Scrum ist unter den agilen Projektmanagement-Methoden – verzeih’ mein Französisch – der heiße Scheiß!

Laut einer Studie von 2022 nutzen über 80 % aller agilen Teams entweder Scrum oder eine Hybrid-Variante. Hauptgrund für zwei Drittel der Befragten: Projekte werden einfach schneller fertig. Produkte können schneller eingeführt werden, die Qualität steigt, das Projektrisiko sinkt.

Erstes Fazit: Der Nutzen von Scrum für dich und dein Team übersteigt den Aufwand der Implementierung erheblich!

Höchste Zeit, diesen Effekt zu nutzen; nur wie ist die Frage?

Die Antwort liefert dir mein ultimativer Scrum-Guide. Als Experte für Projektmanagement und PM-Software von trusted zeige ich dir hier alles, was es über Scrum zu wissen gibt – von der Zusammenstellung deines Projektteams, über das Aufsetzen von Backlogs und To-dos, über die berüchtigten “Sprints” bis hin zum (erfolgreichen) Projektabschluss. Plus aussagekräftige Beispiele und praktische Tipps.

Startklar? Dann auf in die Scrum-Schlacht!

Was lerne ich in diesem Guide?

Definition: Was ist Scrum?

Scrum ist eine Projektmanagement-Methode, mit der komplexe Projekte schnell und günstig umgesetzt werden sollen.

Wichtige Eckpfeiler dafür sind:

  • kurze Planungs- und Projektzyklen (“Sprints”, maximal 4 Wochen)
  • kleine Teams (max. 10 Personen, mit “Product Owner”, “Scrum Master” und “Team”)
  • der tägliche Austausch (“Daily Scrum”)
  • und flexibles Reagieren auf geänderte Anforderungen.

Anstatt Projekte von Anfang an voll bis zum Ende durchzuplanen, setzt Scrum auf ständige Anpassung (Iteration). Wichtig ist nicht die Planung, sondern das fertige Projekt. Zum Beispiel ein Produkt, eine Software oder App, eine Marketing-Strategie, etc.

Die Scrum Methode im Schema
Die Scrum Methode im Schema
Quelle: trusted.de

Aber aufgepasst! Scrum ist keine exakte Wissenschaft, sondern eher ein Framework. Du kannst dich daran orientieren; aber es wird dir nichts bringen, wenn dein Team nicht zu 100% dahinter steht und die Werte verinnerlicht, die für agiles Projektmanagement wichtig sind:

  1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
  2. Funktionierende Projekte sind wichtiger als eine umfassende Dokumentation
  3. Zusammenarbeit mit Kund:innen/dem Management ist wichtiger als Verhandlungen
  4. Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans

Oder anders gesagt: Schneller, effizienter, flexibler und viel weniger Bullshit.

Klingt grundsätzlich gut für dich? Perfekt! Mein Ratgeber soll dir helfen, herauszufinden, ob Scrum dir und deinem Team helfen kann, Projekte schneller, effizienter und günstiger umzusetzen. Als Leitfaden und Schritt-für-Schritt-Anleitung zeigt er dir alles, was du brauchst, um Scrum erfolgreich einzuführen.

Unnützes Wissen: Der Begriff “Scrum” kommt eigentlich aus dem Rugby und bedeutet “Gedränge”. In einem “Scrum” prallen Spieler:innen beider Mannschaften aufeinander und müssen durch kluges Teamwork den Ball an sich bringen. Auch beim Rugby müssen Teams flexibel auf Veränderungen reagieren. Und genau wie beim Rugby ist Scrum auch im Management eine Frage von Training und Teamgeist.

Wann ist Scrum für mich geeignet?

Scrum kommt oft – aber nicht nur – in der Produkt- und Softwareentwicklung zum Einsatz.

Scrum ist für dich geeignet, wenn dein Team oft auf wechselnde Marktbedingungen, neue Technologien und viele Wettbewerber reagieren muss. Wenn dein Team komplexe Problemstellungen schnell, günstig und selbstorganisiert lösen will – oder wenn langwierige Entscheidungsprozesse und festgefahren Strukturen deinen Projekterfolg hemmen – kann Scrum die Lösung sein!

Super beliebt ist Scrum zum Beispiel in diesen Branchen:

  • IT
  • Software- und App-Entwicklung
  • Produktentwicklung
  • Consulting
  • Agiles Marketing
  • Automobilbranche
  • Medizintechnik
  • Kreativagenturen

bzw. für diese Art von Projekten:

  • Innovationsprojekte
  • Software oder Produkte
  • Webdesign
  • Marketing-Strategien
  • Erschließung neuer Geschäftsfelder
  • Kundenorientierte Projekte
  • Dringende Projekte mit einer gewissen Komplexität

Grundsätzlich gilt: Scrum hat zwar seinen Ursprung in Software-Entwicklungsteams, kann aber so gut wie überall zum Einsatz kommen, wo es komplexe Problemstellungen gibt.

Funktioniert Scrum in Remote-Teams?

Einige sagen, dass räumlich getrennte Teams lieber die Finger von Scrum lassen sollten. Aber eigentlich gibt es keinen Grund, warum getrennte Teams nicht erfolgreich scrummen können sollten! Wichtig ist, dass Scrum gelebt wird und dass du dein Team mit den richtigen Werkzeugen unterstützt. Digitale Whiteboards, ein Online-Meeting-Tool für den Austausch, ein Projektmanagement-Tool und ein Cloud-Speicher sind ein guter Anfang!

Wann ist Scrum nicht für mich geeignet?

Wenn dein Projekt ein hohes Maß an Genauigkeit und Wiederholbarkeit verlangt, ist Scrum definitiv der falsche Weg. Auch Arbeiten, die ad-hoc erledigt werden müssen, lassen sich nicht scrummen.

Zwei Beispiele dafür:

Die Industrieproduktion und das produzierende Gewerbe haben mit Scrum wenig am Hut. Hier gibt es bestimmte Produktionsprozesse, die sich bewährt haben und immer nach dem gleichen Muster ablaufen. Eine gleichbleibende Qualität ist essenziell; Iteration im großen Stil sind erstens fehl am Platz und zweitens zu teuer.

Komplex vs. kompliziert – Wo ist der Unterschied?

Von komplizierten Problemen spricht man, wenn Problem und Lösung bekannt sind, die Lösung aber sehr kleinteilig ist. Die Konstruktion einer Uhr ist kompliziert, aber die Uhrmacherin weiß, welche Schritte nötig sind, damit die Uhr funktioniert. Bei komplexen Problemen ist der Lösungsweg unklar, weil ständig neue Herausforderungen auftreten können, auf die reagiert werden muss. Ein Beispiel wäre die Entwicklung eines neuartigen Hybrid-Motors, für den es (noch) keinen Bauplan gibt. Innovation, Trial-and-Error und ständige Anpassungen sind hier die Devise. Dafür ist Scrum super!

Ein großer Hersteller von Reifen z.B. wird in der Produktion niemals mit Scrum arbeiten – sein Design-Team aber ggf. schon!

Zweites Beispiel ist der Service- und Dienstleistungssektor. Auch da gibt es bewährte Prozesse. Vor allem müssen Service-Teams jeden Tag ad-hoc auf Anfragen und Anforderungen reagieren, während Scrum in zwar kurzen, aber fixen Zyklen abläuft. Dein IT-Support-Team kann dem Kunden nicht sagen, dass es sich gerne im nächsten Scrum-Zyklus in 2 Wochen um den Serverausfall kümmert. Das muss sofort passieren!

Kurz und knapp: Scrum eignet sich für komplexe, aber nicht für komplizierte Prozesse; da sind dann eher klassische Projektmanagement-Methoden das Werkzeug der Wahl.

Funktioniert Scrum in Spezialist:innen-Teams?

Nicht so richtig. Wenn dein Team aus hochgradig spezialisierten Mitarbeiter:innen besteht, die meistens alleine an Aufgaben arbeiten, ist Scrum untauglich. In einem solchen Umfeld verzögern der ständige Austausch und die in Scrum so wichtigen Meetings den Arbeitsprozess eher. Das bringt keinen Mehrwert, sondern hält deine Spezialist:innen vom Arbeiten ab. Ergebnis: Langeweile, verschenkte Arbeitszeit und mangelnde Motivation.

Wie führe ich Scrum ein? Der Scrum-Prozess in 7 Schritten

So, nachdem wir das geklärt haben: Lass uns einmal gemeinsam anschauen, wie Scrum im Detail funktioniert und wie du die Methode in deinem Team einführen kannst.

Keine Sorge, wir gehen Schritt für Schritt vor und ich zeige dir alles an einem einfachen Beispiel. Dafür habe ich mir ein fiktives Projekt überlegt, zu dem Scrum als Methode super passt:

Auftritt: trusted Webdesignz. Das Start-up entwickelt und betreut die Internetauftritte von Unternehmen und hat sich auf Online-Shops spezialisiert. Ein Kunde ist der Shop Anime24, ein Versandhändler für Comics, Animes und Merchandise. Anime24 wünscht sich neue Komfortfunktionen für den Shop; z.B. neue Warenkorb-Features, Produktvorschläge und Aktionen wie Rabatte und Co. Das Team von trusted Webdesignz macht sich an die Arbeit!

Ein solches Projekt würde in Scrum grob in 7 Schritten ablaufen:

1. Team zusammenstellen und Rollen verteilen

Das Projektteam wird zusammengestellt; das heißt alle, die am Projekt mitarbeiten, kommen zusammen und starten gemeinsam mit der Planung. In Scrum wird jedem Teammitglied eine feste Rolle zugewiesen: Product Owner, Scrum Master und Developer. Die erkläre ich dir gleich noch ausführlicher!

2. Anforderungen definieren und Product Backlog anlegen

Das Product Backlog beinhaltet alle Anforderungen an das fertige “Produkt” (in unserem Fall den Relaunch des neuen Anime24-Onlineshops). Das Team schwört sich auf diese Vision des fertigen Produkts ein und nimmt es als Basis für alle weiteren Schritte. Es ist quasi eine Art “To-do-Liste”, bzw. eine Liste von Zielen, die erfüllt werden sollen.

3. Tasks planen, Sprint Backlog anlegen und Sprint durchführen

Ein “Sprint” ist eine Projektphase in Scrum, in der aktiv am Projekt bzw. am Produkt gearbeitet wird. Er geht durchschnittlich 2 Wochen. Für jeden Sprint nimmt sich das Team Teile aus dem Product Backlog vor und plant konkrete Aufgaben dazu. Nach jedem Sprint ist dann ein Teil des fertigen Produkts abgeschlossen und der nächste Sprint wird geplant.

4. Scrum-Board aufsetzen

Für jeden Sprint ist das Scrum-Board – das eigentlich nur ein angepasstes Kanban-Board ist – das Instrument, um Fortschritte am Projekt zu tracken, Probleme und Verzögerungen zu identifizieren und Ergebnisse ans Team zu kommunizieren. Alle für den Sprint geplanten Aufgaben landen auf dem Scrum-Board und sind immer für alle sichtbar.

5. Daily Scrums durchführen

Während des Sprints gibt es jeden Tag ein (kurzes!) Meeting, in dem sich das ganze Team austauscht. Neue Erkenntnisse werden diskutiert, mögliche Probleme aus dem Weg geräumt und erste Erfolge gemeinsam gefeiert. Die Daily Scrums sind fester Bestandteil jedes Scrum-Prozesses.

6. Sprint Review durchführen

Nach Abschluss des Sprints werden die Ergebnisse der Projektarbeit präsentiert und bewertet. Das Feedback des Kunden zu den bisherigen Ergebnissen wird eingeholt; auf dieser Basis plant das Team die nächsten Schritte. Also den nächsten Sprint.

7. Sprint Retrospective

Wo es in der Sprint Review um konkrete Arbeitsergebnisse geht, ist die Sprint Retrospective ein Meeting, um Prozesse zu überprüfen. Hier steht also nicht das “was”, sondern das “wie” im Vordergrund. Probleme aus dem letzten Sprint werden diskutiert und Prozesse so angepasst, dass sie im kommenden Sprint nicht mehr auftreten.

Danach geht alles wieder von vorne los, mit dem nächsten Sprint. Im Grunde in simpler Prozess – der aber auch einige Stolpersteine und Tücken birgt und nach mehr oder weniger festen Regeln abläuft.

Bereit, selbst damit durchzustarten?

Damit du einen Einblick bekommst, zeige ich dir im Folgenden die Projektplanung in Scrum anhand des obigen Beispielprojekts, das ich für meinen Guide in unserem PM-Tool monday angelegt habe. monday eignet sich aufgrund seiner Flexibilität prima für die Arbeit mit Scrum; es gibt aber noch viele andere sehr gute Tools, die ich dir später noch im Detail vorstelle.

1. Team zusammenstellen und Rollen verteilen

Als Erstes musst du dein Projektteam zusammenstellen. Ein “klassisches” Scrum-Team besteht aus nicht mehr als 10 Personen mit festen Rollen:

  • 1 Product Owner
  • 1 Scrum Master
  • 3 - 8 Developer (Entwickler:innen)

Also: ein Mitglied ist für die Vision des fertigen Produkts verantwortlich, eines für die Scrum-Prozesse und der Rest des Teams für die operative Projektarbeit.

Die Rollen in einem Scrum-Team im Überblick
Die Rollen in einem Scrum-Team im Überblick
Quelle: trusted.de

In unserem Beispiel besteht das Team aus 5 Personen: Robert als Product Owner, Naomi als Scrum Master und Steve, Mattis und Wiebke als Developer. Ich stelle sie dir unten näher vor.

Das ist die erste wichtige Hürde im Scrum-Prozess: Scrum kann nur funktionieren, wenn alle Mitglieder des Teams ihre Rolle kennen und ausfüllen. Überschneiden sich Aufgabenbereiche, führt das fast immer zu Missverständnissen und Chaos. Darum ist die feste Rollenverteilung in Scrum so wichtig!

Schauen wir uns die Rollen im Detail an:

Product Owner

Der Product Owner (oder Produkteigentümer:in) ist quasi der Produktmanager.

Er ist verantwortlich für die Entwicklung und den wirtschaftlichen Erfolg des Projekts. Und er tauscht sich mit den “Stakeholdern” aus. Das sind Kund:innen, Auftraggeber:innen oder auch die Geschäftsleitung – also diejenigen, die das Projekt angestoßen haben.

In kleinen Teams kann es sein, dass Stakeholder und Product Owner ein und dieselbe Person sind. In den meisten projektbasierten Teams (Agenturen und Co.) sind die Stakeholder aber eher “Externe”, also eben Kund:innen.

Der Product Owner nimmt die Anforderungen der Auftraggeber:innen mit ins Team, ist für die Erstellung des Product Backlogs zuständig und verteilt die Aufgaben.

In unserem Beispiel übernimmt Robert als Geschäftsführer von trusted Webdesignz die Rolle des Product Owners. Er steht im engen Austausch mit den Auftraggeber:innen von Anime24 und hat von ihnen den Auftrag zum Website-Relaunch bekommen, mit allen Wunschfunktionen und Anpassungen. Jetzt stellt er dafür sein Team zusammen.

Die konkreten Aufgaben des Product Owners sind:

Kommunikation

Der Product Owner ist die Schnittstelle zwischen Stakeholder und Team. Er hält einerseits die Stakeholder über die Erfolge und Ergebnisse des Teams auf dem Laufenden und vermittelt andererseits das Feedback der Stakeholder zurück ins Team. Wenn Kund:innen während des Projekts eine Änderung wünschen, kümmert sich der Product Owner um die Anpassungen am Product Backlog und trägt die neuen Anforderungen ins Team.

Erfolgskriterien

Erfolge im Projekt müssen messbar sein; deswegen hat der Product Owner die Aufgabe, für jeden Eintrag im Product Backlog klar zu definieren, wann es als “fertig” gilt. So weiß das Team exakt, was es erreichen muss. Ein Kriterium für Erfolg kann z.B. sein, dass ein neue erstelltes Feature funktioniert – quasi ein Ja/Nein-Kriterium. Es kann sich aber auch in Zahlen widerspiegeln; zum Beispiel “Verbesserung des Pagespeeds um 50 %”.

Risikomanagement

Der Product Owner ist auch für die Bewertung von möglichen Risiken zuständig und leitet schon in der Planung Maßnahmen ein, um Risiken zu minimieren. Steht z.B. bereits eine neue Technologie in den Startlöchern, die die Software, die das Team gerade entwickelt, obsolet machen würde? Dann muss der Product Owner entscheiden, wie darauf zu reagieren ist – mit Abbruch, einem schnelleren Projektabschluss oder der Vorveröffentlichung einzelner Softwarebestandteile.

Ressourcenmanagement

Product Owner tauschen sich auch mit der Geschäftsleitung aus und besorgen alle nötigen Ressourcen für ihr Team. Gerade in größeren Unternehmen kann es passieren, dass Abteilungen oder Mitarbeiter:innen mehrfach verplant werden. Braucht das Projektteam bestimmte Kompetenzen unbedingt, muss der Product Owner diese Ressourcen einfordern. Das betrifft auch das Budget für das Projekt – das sich laufend verändern kann.

Wichtig: Der Product Owner ist immer eine Einzelperson und niemals ein Gremium oder eine Gruppe!

Scrum Master

Scrum Master sind nichts anderes als Projektmanager:innen. Sie sind zugleich Coaches, Moderator:innen und Planer:innen. Scrum Master …

  • … planen und kommunizieren alle Meeting-Termine (wie Sprint-Planung, Daily Scrums, Reviews, Retrospectives und Co.; siehe unten)
  • … sorgen dafür, dass alle im Team ihre Rolle einhalten (und sich keiner als Chef aufspielt)
  • … kümmern sich darum, dass die Prinzipien agilen Arbeitens und die Werte von Scrum (siehe unten) verstanden und gelebt werden.

Bei Problemen im Team vermittelt der Scrum Master zwischen den Gruppen. Er begleitet das Team durch Meetings und ist die zentrale Anlaufstelle für Prozessfragen.

Wohlgemerkt: Nicht zu Fragen, die direkt die Projektinhalte betreffen! Denn dafür gibt es ja den Product Owner.

Im fiktiven Projekt-Team von trusted Webdesignz übernimmt Naomi als Kommunikationstalent und Kundenservice-Expertin diesen Posten. Sie hat bereits mit Scrum gearbeitet und ihre Kompetenzen sind in der eigentlichen Projektarbeit nicht gefragt, sodass sie den Posten des Scrum-Masters gut ausfüllen kann. Am Anfang des Projekts verschafft sie sich einen Überblick und plant den Termin für den ersten Sprint.

Die Aufgaben des Scrum Masters im Überblick:

Teamwork und Kommunikation

Scrum Master sorgen dafür, dass das Team störungsfrei arbeiten kann. Sie unterstützen das gesamte Team bei der Kommunikation und haben die Scrum-Praktiken und Werte im Blick. Insbesondere im Projektstress können für Scrum elementare Werte wie Respekt, Offenheit und Fokus schnell flöten gehen. Der Scrum Master als neutrale Instanz glättet die Wogen und sorgt für ein produktives Miteinander.

Coaching

Jedes Team hat eine eigene Dynamik und besteht aus unterschiedlichen Individuen mit eigener Persönlichkeit. Einige verinnerlichen Prozesse, Rollen und Regeln sehr schnell, während andere mehr Unterstützung brauchen. Scrum Master achten auf die Bedürfnisse aller Teammitglieder und gehen gezielt darauf ein, um alle im Team auf das gleiche Level zu bringen.

Servant Leadership

Scrum Master sind die Beseitiger:innen von Problemen und Hindernissen, die den Projektfortschritt gefährden. In Scrum werden sie auch “Impediments” genannt und können ganz banal sein: Ein Meetingraum ist blockiert und das Team kann sich nicht richtig austauschen. Es fehlt an der nötigen Technik für einen Remote-Austausch. Oder es gibt ständig Ablenkungen durch andere Projektteams. Scrum Master finden diese “Impediements” und eliminieren sie – wenn nötig durch den Gang zum Management.

Oder kurz: Alles, was mit Prozessen und Abläufen zu tun hat, liegt in der Verantwortung des Scrum Masters. An der eigentlichen Projektarbeit ist der Scrum Master nicht bzw. kaum beteiligt.

Es ist wichtig, den Unterschied zwischen Scrum Master und Product Owner zu verstehen. Beide haben eine “leitende” Funktion, aber ihre Aufgabenbereiche sind grundverschieden. Einfach gesagt: Während du den Product Owner fragen würdest: “Was sind die Ziele des aktuellen Sprints?”, würdest du den Scrum Master fragen: “Wie lange dauert der aktuelle Sprint noch?”. Inhalte vs. Prozesse. Soweit klar?

Team/Developer

Die Developer oder “Entwickler:innen” sind schließlich der Kern eines Scrum-Teams. Sie kümmern sich um die operative Arbeit und “schrauben” am Projekt.

Obwohl sie “Entwickler:innen” heißen, müssen sie nicht zwangsläufig etwas mit Software am Hut haben. Auch Mitarbeiter:innen aus dem Marketing, dem Design oder aus anderen Bereichen gehören in ein Scrum-Team – sofern ihre Kompetenzen für den Projekterfolg gebraucht werden.

In unserem Beispiel übernehmen die beiden Entwickler:innen Steve und Mattis sowie die Grafikerin Wiebke die Rolle der Developer. Sie werden dafür zuständig sein, die neuen Features für den Online-Shop zu programmieren und ggf. Anpassungen am Design der Page vorzunehmen, wo nötig. Sie arbeiten also direkt am Projekt.

Ein Scrum-Team ist immer unabhängig und selbstorganisiert!

Input und Beratung von außen sind zwar nicht unerwünscht – sollten aber nicht Voraussetzung für eine erfolgreiche Projektarbeit sein.

Eine mehr oder weniger lose Regel: Bei der Auswahl eines Scrum-Teams sind Teammitglieder mit breitgefächerten Kenntnissen Spezialist:innen vorzuziehen. Wer zu stark spezialisiert ist, kann nur in seinem Bereich etwas beitragen. Aber das ist natürlich von Projekt zu Projekt unterschiedlich und oft ist Spezialwissen ja auch nötig. Dann muss bei der Teamzusammenstellung geschaut werden, wie man dieses Wissen einbringt.

2. Projektanforderungen definieren und Product Backlog anlegen

Das Product-Backlog ist eine Liste mit allen Punkten, die für das Projekt erfüllt sein müssen.

Sehr vereinfacht gesagt, kannst du dir das Product Backlog wie eine Art Must-have-Liste vorstellen. Hier stehen also alle Anforderungen, die das Management oder deine Kund:innen an das fertige Produkt, die Software oder App oder ganze einfach den Outcome des Projekts setzen.

Jede dieser Anforderungen ist ein “Item” im Product Backlog. Das kann vielleicht ein Feature sein, das die Software unbedingt haben soll.

Alles, was im Product Backlog steht, ist wichtig. Aber einige “Items” sind wichtiger als andere. Gewisse “must haves” sind nicht verhandelbar, bei einigen “nice to haves” hast du mehr Spielraum. Relevant ist nur, dass das Product Backlog definiert, wann das Projekt abgeschlossen ist – nämlich, wenn alle Anforderungen erfüllt sind und die Stakeholder mit dem Outcome zufrieden sind.

Schauen wir uns das im Detail an:

Wer erstellt das Product Backlog? Grundsätzlich fällt das Product Backlog in die Zuständigkeit des Product Owners. In Abstimmung mit den Stakeholdern definiert er, welche Items im Product Backlog stehen und welche Priorität sie haben. Bei Bedarf kann der Product Owner aber Teile des Teams zur Beratung hinzuziehen – z.B. bei technischen Fragen, die eine weitere Einschätzung benötigen.

Was steht im Product Backlog? Ein Product Backlog ist eine priorisierte Liste von Anforderungen, die das Projektergebnis erfüllen muss. Jeder Eintrag im Product Backlog steht also für eine zu erfüllende Anforderung. Wie diese genau hinterlegt wird, ist dir überlassen. Es kann bereits eine konkrete Aufgabe sein, oder ein grober Wunsch der Stakeholder. Wichtig ist nur, dass das Entwicklerteam alle “Items” verstehen und umsetzen kann.

Bezogen auf unser Beispiel könnte ein Product Backlog Item also beispielsweise ein neues Warenkorb-Feature sein, das es Shop-Besucher:innen ermöglicht, gefundene Artikel zunächst abzuspeichern. Aufgabe des Teams ist es dann, im Sprint Planning eine eigene Schätzung abzugeben, wie viel Aufwand die Umsetzung des Items erfordert. Was ein Sprint Planning genau ist und wie es abläuft, erfährst du im nächsten Schritt.

Was ist das Ergebnis? Eine klare Vision des fertigen Produkts bzw. des Projekt-Outcomes. So gesehen eine Liste von Anforderungen, die erfüllt werden müssen, priorisiert von oben nach unten. Ganz oben stehen die wichtigsten “must haves”, weiter unten die Punkte, die ggf. noch verhandelbar sind. Ziel: Das Team muss durch einen einzigen Blick auf das Product Backlog verstehen, wie das Ergebnis aussehen soll.

In unserem Beispiel-Projekt ist der Relaunch eines Onlineshops für den Anbieter Anime24 geplant. Ziel des Projektes ist die Implementierung der erwähnten Warenkorb-Features und neuer Komfortfunktionen für Kund:innen. Dazu gehören hinterlegte Zahlungsdaten, Express- sowie Gast-Checkouts und Userprofile. Weil die Warenkorbfunktion die wichtigste Neuerung darstellt, steht sie ganz oben im Produkt Backlog. Danach folgen die Zahlungsdaten, während der Gast-Checkout nur eine nachgeordnete Priorität hat und ganz zum Schluss umgesetzt werden soll.

Wie ein Product Backlog für unser konkretes Beispiel aussehen könnte, siehst du hier:

So könnte das Product Backlog für die Überarbeitung eines Onlineshops aussehen
So könnte das Product Backlog für die Überarbeitung eines Onlineshops aussehen
Screenshot: trusted.de
Quelle: monday.com

Können Einträge im Product Backlog geändert werden? Ja. Das Product Backlog ist “lebendig” und kann jederzeit durch den Product Owner angepasst werden. Wichtig ist, dass die Veränderungen verständlich und transparent sind. Außerdem kann der Product Owner die Priorisierung einzelner Items verändern, beispielsweise wenn die Stakeholder ein entsprechendes Feedback geben.

Es kann immer vorkommen, dass sich die Anforderungen an ein Produkt verändern, hier muss dann der Product Owner natürlich entsprechend reagieren. Das Product Backlog bietet diesen Spielraum.

Ist das Product Backlog fertig, kann es mit der Projektarbeit losgehen. Der erste “Sprint” wird geplant!

Vorher aber noch kurz ein paar wichtige Begriffe im Zusammenhang mit dem Product Backlog:

Product Goal

Das Product Goal ist Teil des Product Backlogs und steht für das übergeordnete Ziel einer Produktentwicklung. Ohne zu detailliert zu sein, muss das Product Goal dennoch einige Merkmale beschreiben. Was wird mit dem Produkt an positiven Veränderungen erreicht? Welche Wertigkeit in Bezug auf den Nutzen hat das Produkt? Daneben sind Begrenzungen, also beispielsweise Zielgruppen, Kunden und Stakeholder wichtig. Verantwortlich für das Produktziel ist der Product Owner.

Definintion of Ready

Die Definition of Ready (kurz DoR) beschreibt Items des Product Backlogs, die so weit ausgearbeitet und beschrieben sind, dass sie bereit sind, in das Sprint Backlog als konkrete Arbeitsanweisung übernommen zu werden. Damit stellt die Definition of Ready sicher, dass alle Anforderungen bekannt sind und das Entwicklerteam während des Sprints keine Unklarheiten mehr ausräumen muss. Die DoR soll also verhindern, dass der Arbeitsfluss während des Sprints unterbrochen wird.

3. Sprint Planning durchführen

Im Sprint Planning legt das Team fest, welche Anforderungen des Product Backlogs im nächsten “Sprint” – also in den nächsten 1 bis 4 Wochen – erledigt werden sollen. Dabei legst du im Meeting mit dem Team konkrete Ziele fest und definierst, wie diese Ziele erreicht werden können. Digital oder persönlich ist dabei eigentlich egal. Wichtig ist nur, dass alle Projektbeteiligten am Start sind.

Das Ergebnis der Planung ist das Sprint Backlog; eine To-do-Liste für die nächsten Schritte.

Das klingt komplexer, als es eigentlich ist. Schauen wir uns mal an, wie so eine Sprint-Planung konkret abläuft:

Wer ist beteiligt? Alle; das heißt: der Product Owner, der Scrum Master und alle Mitglieder des Development-Teams. Der Product Owner definiert das gewünschte Ergebnis des nächsten Sprints, das Team diskutiert die dazu nötigen Aufgaben und der Scrum Master hält alles in geordneten Bahnen.

Warum ausgerechnet 2 Wochen?

Das ist nur ein grober Richtwert, der sich aber in vielen Teams durchgesetzt hat. 2 Wochen sind eine überschaubare und planbare Zeit. Die Kurzfristigkeit wirkt motivierend, mögliche Projektbremsen werden früher erkannt. Außerdem steht das ganze Team so regelmäßig im Austausch. Die exakte Zeit ist nicht in Stein gemeißelt; kleinere Teams können auch längere Sprints planen. Recht viel länger als 1 Monat sollte ein Sprint aber nie sein.

Was wird geplant? Für den Sprint nimmst du dir die Punkte aus dem Product Backlog vor, die du in den nächsten 1 bis 4 Wochen mit deinem Team erreichen willst bzw. erreichen kannst. Das kann ein konkretes Teilergebnis des Projekts sein; es können aber auch Aufgaben sein, die vorbereitend für spätere Tasks erledigt werden müssen.

Während des Sprints arbeitet das Projektteam nur an diesen Tasks, nicht an anderen Punkten des Product Backlogs. Deswegen sind Sprints auch so kurz angelegt; meistens sind es 2 Wochen. Das erlaubt es deinem Team, mit “Laser Focus” an den Zielen zu arbeiten.

In der ersten Sprint-Planung eines neuen Projekts geht es auch darum, dem Team das fertige Product Backlog vorzustellen und sie auf die “Vision” des fertigen Projekts einzuschwören.

Wie wird geplant? Im Grunde ist eine Sprint-Planung eine Verhandlung. Der Product Owner kann zwar – auf Basis des Product Backlog – vorgeben, welches Ziel erreicht werden soll. Aber letztlich muss das Team beurteilen, ob das Ziel realistisch ist und was dafür nötig ist. Dabei kann (und soll) jedes Teammitglied Input geben. Auch die Ergebnisse des letzten Sprints und das bisherige Feedback der Stakeholder sind wichtig!

Bei der Planung von Zielen hältst du dich am besten an die SMART-Regel. Das heißt, deine einzelnen Ziele sind “specific” (spezifisch), “measurable” (messbar), “achievable” (erreichbar), “relevant” und “time-bound” – also zeitlich umrissen, mit klaren Deadlines.

Eine meiner Lieblingsmethoden für die Sprint-Planung ist das “Planning Poker”. Das zeige ich dir später noch im Detail, aber im Grunde läuft das so, dass alle im Team unabhängig voneinander einschätzen, wie schwierig eine Aufgabe umzusetzen ist. Das kann helfen, Diskussionen in Gang zu bringen und Input aus dem Team “herauszukitzeln”. Oder mögliche Stolpersteine zu erkennen. So etwas zu nutzen ist aber kein Muss.

Was ist das Ergebnis? Der fertige Sprint Backlog enthält die Aufgaben und Ziele der kommenden Wochen und ist die Basis für das Scrum-Board. Ab jetzt kann dein Team anfangen, am Projekt zu arbeiten.

Ergebnisse und Probleme während des Sprints werden festgehalten und am Ende in der Sprint Review (siehe unten) diskutiert. So kannst du, wenn dein Team während des Sprints auf Probleme stößt, im nächsten Sprint darauf reagieren. Oder hast (wenn alles glattläuft) ein Teilergebnis, das du an deine Stakeholder kommunizieren kannst.

Wie sieht ein Sprint Backlog aus? Ein Sprint Backlog kann so ziemlich alles sein; handschriftliche Notizen, ein Word-Dokument, eine Mindmap oder ein Whiteboard. Für die bessere Übersicht sollte der Scrum Master das Backlog nach der Planung trotzdem in eine saubere Form gießen. Dafür kann eine Excel-Tabelle herhalten; noch besser ist ein Projektmanagement-Tool mit Kanban-Board.

Immer noch zu abstrakt? Kein Problem; hier mal ein beispielhaftes Sprint Backlog, wie wir es für unser Beispiel-Projekt “Website-Relaunch” hätten anlegen können:

Für den ersten Sprint bei trusted Webdesignz stet das Warenkorb-Feature im Vordergrund. Die Anforderungen sind klar und stammen aus dem Product Backlog: Kund:innen von Anime24 sollen in Zukunft einzelne Artikel dem Warenkorb hinzufügen und wieder entnehmen können. Das erfordert ein passendes Design für die Checkout-Seiten, die Planung der Datenbank-Tabelle, die Entwicklung des nötigen Codes, die Implementierung und eine Testphase des neuen Features. All diese Tasks bilden zusammen den Sprint Backlog des ersten Sprints.

Ein wichtiger Begriff, den du im Zusammenhang mit den Sprints kennen solltest:

Sprint Goal

Ein Sprint Goal beschreibt das zum Ende eines Sprint-Zyklus durch das Scrum-Team zu erreichende Ergebnis. Das Ziel wird durch den Product Owner definiert, der hierbei darauf achten sollte, dass jedes Sprint Goal spezifisch und messbar ist. Außerdem hat das Scrum-Team ein allgemeines Mitspracherecht und muss die vorgegebenen Ziele akzeptieren. Damit soll erreicht werden, dass Ziele auch erreichbar sind.

4. Aufgaben verteilen und Scrum-Board aufsetzen

Das Scrum-Board (oder Scrum-Taskboard) ist eines der wichtigsten Instrumente des Scrum-Teams. Es gibt Auskunft über den aktuellen Stand eines Sprints und listet alle Sprint-Backlogs nach Arbeitsstand und Status.

In der ersten Spalte stehen die User Storys, also konkrete Anforderungen an das Produkt, aus denen Aufgaben für das Entwicklerteam abgeleitet werden. Diese To-dos stehen in der zweiten Spalte und werden (analog zu Kanban-Boards) je nach Status weiter nach rechts verschoben:

  • In Planung (To do)
  • In Arbeit (Doing)
  • Im Test (Verify)
  • Abgeschlossen (Done)

Erst, nachdem ein Task getestet bzw. geprüft oder abgesegnet wurde, landet er in der Spalte “done” – und gilt damit als abgeschlossen.

Wichtig: Jedes Scrum-Team muss den Status “done” exakt definieren. Ziel sollte es sein, dass jede erledigte Aufgabe als Teilprodukt (oder “Increment”) den Stakeholdern präsentiert und ausgeliefert werden kann. Das bedeutet: Jedes “Increment” soll voll einsatzfähig und kundentauglich sein.

Wie ein Scrum-Board für unser Beispielprojekt aussehen könnte, siehst du hier:

So könnte ein Sprint Backlog für unser Beispiel-Projekt aussehen
So könnte ein Sprint Backlog für unser Beispiel-Projekt aussehen
Screenshot: trusted.de
Quelle: monday.com

Im Beispiel siehst du die Userstory “Artikel im Warenkorb hinterlegen”. In der Sprint-Planung wurden für diese Anforderung schon alle nötigen Tasks geplant, die nun als einzelne “Tickets” oder “Karten” auf dem Board verteilt werden. Gleichzeitig wird definiert, wer für welche Aufgabe zuständig ist. So sehen alle im Team, wo die Verantwortlichkeiten liegen und was jeder einzelne zu tun hat.

Übrigens: Viele Scrum-Teams arbeiten mit einer Art “Informationszentrale”. Das kann beispielsweise ein Meetingraum sein, der genügend Platz für Whiteboards und Pinnwände bietet. Hier lassen sich dann problemlos Mindmaps und Scrum-Boards aufstellen und anpinnen. Jedes Teammitglied kann sich selbstständig auf einen Blick informieren.

Diese Infozentrale lässt sich natürlich auch durch eine digitale PM-Software aufsetzen, was sich für Remote-Teams besser eignet und platzsparender ist. Hier hat jedes Team seine ganz eigenen Ansprüche und Vorlieben.

Ein paar wichtige Begriffe, die du zum Kanban-Board kennen solltest:

User Storys

Eine User Story ist eine aus Kundensicht verfasste Anforderung an eine Software-Anwendung oder ein Produkt. Die User Story ist kurz und einfach in Alltagssprache gehalten und soll ein Kundenbedürfnis an einem Produkt beschreiben. Dieses Kundenbedürfnis dient als Diskussions- und Arbeitsgrundlage für das Scrum-Team, das daraus dann konkrete Funktionen und Fähigkeiten ableitet und umsetzt.

Story Points

Jede User Story steht zwar für eine Anforderung; jedoch können einzelne User Storys ganz unterschiedlich sein, was den Aufwand in der Umsetzung angeht. Damit Scrum-Teams besser bewerten können, wie viel Entwicklungsaufwand hinter einer User Story steckt, kannst du beim Anlegen deines Scrum-Boards “Story Points” vergeben. Stell sie dir als Maßeinheit vor, um Relevanz, Komplexität, Zeiteinsatz und Risiko einer User Story abzuschätzen.

Definition of Done

Die Definition of Done (oder DoD) ist ein gemeinsames Verständnis des Scrum-Teams, wann eine Arbeit als erledigt gilt. Die DoD ist zwar im offiziellen Scrum-Guide definiert und hinterlegt, wichtig ist aber, dass sich jedes Scrum-Team auf eine Definition einigt, die den Anforderungen des Projektes gerecht wird. Mit der Definition of Done soll sichergestellt werden, dass Product Increments tatsächlich auch abgeschlossen und fertig (“done”) sind. De DoD hilft also, Nacharbeiten zu vermeiden.

Ist das Scrum-Board aufgesetzt, geht es an die Projektarbeit. Das heißt: Jetzt endlich verlässt das Team die graue Theorie und macht sich an die Arbeit, die geplanten Aufgaben umzusetzen. Der Sprint beginnt. Innerhalb der nächsten Wochen wird das Team fokussiert an den geplanten Tasks arbeiten und sich in “Daily Scrums” regelmäßig dazu austauschen.

5. Tägliche Abstimmung im Daily Scrum

Wie der Name schon verrät, ist der Daily Scrum ein täglich stattfindendes Meeting des Scrum-Teams. Es dient der Team-Synchronisation, dem allgemeinen Austausch und der Koordination von Aufgaben.

Wer nimmt am Daily Scrum teil? Am Meeting nehmen das gesamte Developer-Team und der Scrum Master teil. Je nach Möglichkeit und Bedarf kann auch der Product Owner hinzugezogen werden – er muss aber nicht täglich erscheinen.

Was wird besprochen? Der Daily Scrum funktioniert wie eine tägliche Besprechung der anstehenden Aufgaben. Aktuelle Fortschritte können so verfolgt und etwaige Probleme frühzeitig erkannt werden. So kann jedes Teammitglied seine Arbeit mit dem gesamten Team abstimmen und ist auf dem aktuellen Stand. Insgesamt soll das tägliche Meeting die Selbstorganisation des Teams stärken und die Zusammenarbeit verbessern.

Während der Daily Scrums können z.B. Tasks im Scrum Board verschoben werden. Außerdem kannst du hier in deinem Team Probleme besprechen, die während der Projektarbeit aufgetreten sind. Wenn sich ein Task verzögert, mehr Ressourcen verbraucht, als vorgesehen oder komplett blockiert wird, hat das ganze Team die Probleme auf dem Schirm. Es kann sie dann ausräumen oder auf die Agenda für den nächsten Sprint setzen.

Wie lange dauert ein Daily Scrum? Die vorgesehene Timebox für das Daily Scrum liegt bei 15 Minuten und sollte die angesetzte Zeit nicht überschreiten.

Im ersten Daily Scrum sind Steve, Mattis und Wiebke anwesend, um die anstehenden Aufgaben zu besprechen und sich abzustimmen. Naomi moderiert das Meeting. Steve und Mattis sind mit ihren Aufgaben on track; sie sind gut gelaunt und scherzen. Naomi ruft die beiden höflich zur Ordnung, damit auch Wiebke ihre Ergebnisse noch teilen kann, ohne die Timebox zu sprengen. Tatsächlich hat Wiebke ein Problem. Ihr Mockup der Checkout-Page dauert länger, als geplant, da eine Anforderung an das Design unklar formuliert war. Das könnte Steve und Mattis später im Sprint in ihren Aufgaben blockieren; noch ist das Sprintziel aber nicht ernsthaft gefährdet. Nach 15 Minuten endet das Meeting und das Team macht sich wieder an die Arbeit. Naomi wird sich nun mit dem Product Owner Robert abstimmen und ihn zum nächsten Daily Scrum einladen, damit er sich einen Überblick verschaffen kann. Er wird dann ggf. die Anforderungen im Backlog präzisieren – oder im Zweifel noch einmal Rücksprache mit Anime24 halten.

6. Ergebnisse im Sprint Review prüfen

Am Ende eines Sprints – also nach 1 bis 4 Wochen Arbeit – endet der Sprint und die Sprint Review findet statt.

Im Grunde ist das eine Abnahme für alles, was während des Sprints passiert ist. Die Developer stellen ihre Ergebnisse dem Product Owner vor, der sie begutachtet und anhand der Anforderungen überprüft.

Wie läuft das konkret ab?

Wer ist bei der Sprint Review dabei? Auch hier ist wieder das gesamte Team anwesend, damit sich alle zu den Ergebnissen austauschen können. Stakeholder müssen nicht unbedingt dabei sein; im Sinne der Kundenzufriedenheit und Transparenz sind sie aber stets willkommen und werden bei Bedarf vom Product Owner rechtzeitig eingeladen.

Was wird in der Sprint Review besprochen? Hier werden nur Ergebnisse vorgestellt und Feedback eingeholt – vom Product Owner und/oder von den Stakeholdern. Sollten die Ergebnisse nicht den Anforderungen entsprechen, bekommt das Team eine entsprechende Rückmeldung und kann im nächsten Sprint die Fehler beseitigen oder Korrekturen vornehmen.

Diese kurze Iteration ist der große Vorteil von Scrum, denn: Durch die kurzen Zyklen und die ständige Möglichkeit zur Anpassung ist ein Projekt niemals in Gänze in Gefahr. Das ständige Hamsterrad aus Entwicklung, Prüfung und Abnahme ermöglicht es deinem Team, blitzschnell auf neue Bedingungen zu reagieren.

Die Sprint Review kann – muss aber nicht – den Abschluss eines Projekts markieren. Wenn alle Items des Backlogs umgesetzt wurden und das Ergebnis den Anforderungen entspricht, ist das Projekt an dieser Stelle abgeschlossen. Die Stakeholder erhalten den Outcome, dein Team kann sich auf das nächste Projekt stürzen.

Falls noch nicht alle Anforderungen umgesetzt wurden, folgt nach dem ersten der zweite Sprint und dann der dritte und vierte … solange, bis das Projektergebnis alle Anforderungen erfüllt.

In unserem Beispiel:

Das fertige und intern bereits geprüfte Warenkorb-Feature wird während der Sprint-Review dem Product Owner Robert vorgestellt. Auch Ayla, eine Vertreterin von Anime24, ist mit dabei, um sich die Funktion vorführen zu lassen und sich die neue Checkout-Page anzuschauen. Alles läuft glatt; das neue Feature funktioniert und kann ausgespielt werden. Ayla macht noch ein paar Verbesserungsvorschläge am Aufbau und der Farbgebung der neuen Page, die das Team in den nächsten Sprint mitnehmen kann. Wiebke wird sich dann um die nötigen Änderungen kümmern.

Du siehst, Scrum funktioniert nur dank ständiger Kommunikation, Transparenz und Anpassungsfähigkeit. Das Ende eines Sprints markiert immer den Anfang des nächsten und alle Erfahrungen des ersten Zyklus gehen in den zweiten ein. Eigentlich easy, oder?

Bevor du allerdings komplett die Waffen niederlegen kannst, gibt es noch einen fixen Termin, den du beachten solltest: Die Sprint Retrospective.

7. Prozesse durch die Sprint Retrospective optimieren

Nach der Sprint Review folgt die “Sprint Retrospective”. Auch das ist ein festes Meeting in jedem Scrum-Prozess und quasi eine Art “Nachbesprechung”; gleichzeitig aber auch der Startschuss für den nächsten Sprint. Sprint Retrospective und Sprint Planning werden deshalb oft auch direkt “hintereinander” geplant.

Aber halt, wirst du jetzt sagen: Ein zweites Meetings für den Abschluss? Hätte nicht auch eines gereicht?

Schauen wir’s uns an:

Wer ist an der Sprint Retrospective beteiligt? Hier kommen das Entwicklerteam und der Scrum Master zusammen und besprechen den Ablauf des letzten Sprints. Der Product Owner und die Stakeholder sind (in der Regel) nicht mit dabei – was schon einmal einen Unterschied zur “Sprint Review” markiert. Denn hier geht es primär um die Arbeit der Developer. Der Scrum Master leitet und moderiert das Ganze.

Was wird in der Retrospective besprochen? Das Team bespricht den letzten Sprint, besondere Vorkommnisse und positive sowie negative Aspekte der Projektarbeit. Während die Sprint Review also vor allem den Outcome des Projekts an sich im Blick hat, geht es in der Retrospective primär um die Verbesserung von Prozessen, Abläufen und Kommunikation.

Was ist das Ergebnis der Retrospective? Ziel soll es sein, Probleme zu ermitteln und den kommenden Sprint anhand der gewonnenen Erkenntnisse zu optimieren.

Im ersten Sprint gab es einige Erkenntnisse, die für die Planung des nächsten Sprints ausschlaggebend sein könnten. In einem der späteren Dailys hat sich herausgestellt, dass Steve und Mattis sich trotz Scrum-Board nicht richtig abgestimmt hatten, und parallel an der gleichen Aufgabe gearbeitet haben. Das Feature konnte zwar umgesetzt werden; trotzdem hat die Doppelbearbeitung Zeit gekostet. Unter anderen Bedingungen hätte das die Gefährdung des Sprint-Ziels bedeutet. Naomi erinnert die beiden daran, das Board als Instrument ernstzunehmen und zu nutzen und zeigt ihnen noch einmal, wie sie Verantwortlichkeiten im Board einstellen können. So hat das Team für den nächsten Sprint eine wertvolle Lektion gelernt. Alle gehen voller Elan in die weitere Planung.

So; jetzt weißt du, wie die Planung eines Scrum-Zyklus funktioniert und wie du Projekte in deinem Team mit Scrum planen kannst.

Eigentlich hättest du damit schon alles, um loszulegen. Trotzdem solltest du hier noch nicht Schluss machen, denn ich habe noch einige coole Tipps und Hintergrundinfos für dich, die dir auf deiner Scrum-Reise mit Sicherheit nützlich sein werden:

Was brauche ich für Scrum? Wichtige Werkzeuge und Hilfsmittel

Das passende Projektmanagement-Tool

Nicht unbedingt essenziell, aber super hilfreich für Scrum ist eine smarte PM-Software.

Die hilft dir, eine digitale Einsatzzentrale für dein Team zu schaffen und ist in der Regel bequemer, als analoge Whiteboards. Außerdem ist es vor allem für Remote-Teams – die nicht einfach “eben schnell einen Blick an die Bürowand werfen können” – toll, um über alles auf dem Laufenden zu bleiben.

monday ist flexibel einsetzbar und eignet sich optimal für agile und hybride Teams
monday ist flexibel einsetzbar und eignet sich optimal für agile und hybride Teams
Screenshot: trusted.de
Quelle: monday.com

Der Scrum-Prozess fällt in das Themengebiet “Agiles Projektmanagement” und benötigt besondere Funktionen und Tools, die in klassischen PM-Lösungen nicht oder nur teilweise vorhanden sind.

Daher ist es wichtig, ein Tool zu finden, das alle für Scrum wichtigen Eigenschaften mitbringt – zum Beispiel die Möglichkeit, ein Scrum-Board aufzusetzen, Aufgaben zu planen und zuzuweisen, Kommentare zu hinterlassen oder Ergebnisse in Dokumenten festzuhalten.

Ein paar meiner persönlichen Favoriten für den Scrum-Prozess habe ich dir hier einmal übersichtlich aufgelistet:

monday.com ist ein großartiges Tool für agiles Projektmanagement und zu Recht Sieger im aktuellen trusted-Test. Ein Vorteil von monday.com ist der flexible Einsatz im Projekt-, Aufgaben- und Workload-Management. Zusätzlich musst du dich nicht sklavisch an Scrum halten, weil monday.com auch klassische bzw. hybride PM-Praktiken unterstützt. In monday ist auch unser Beispielprojekt entstanden!
Asana ähnelt in vielen Belangen monday.com und ist ähnlich vielfältig einsetzbar. In Sachen Bedienung und Benutzerfreundlichkeit ist Asana sogar die etwas dankbare Lösung und benötigt nur eine geringe Einarbeitungszeit. Außerdem glänzt Asana mit zahlreichen, sehr einfach zu nutzenden Automatisierungen.
awork ist eine PM-Lösung aus Deutschland und zeichnet sich neben der modernen Optik durch eine hohe Benutzerfreundlichkeit aus. Kleine Lücken hat das Tool lediglich im Bereich der Ressourcenplanung. Im Vergleich zu monday.com ist Awork die etwas schlankere Lösung, für kleine Teams aber definitiv eine gute Wahl.
MeisterTask stammt ebenso wie Awork aus Deutschland und hat seine große Stärke im agilen Aufgabenmanagement. Außerdem glänzt MeisterTask durch sein modernes und übersichtliches Design: Hier finden sich neue User sofort zurecht. Lediglich im Multiprojektmanagement zeigt die Anwendung Schwächen. Kleine und mittlere Teams finden in MeisterTask eine vielseitige Lösung für hybrides oder agiles Projektmanagement.
Jira stammt ursprünglich aus der Software-Entwicklung und bringt einen vergleichsweise großen Funktionsumfang mit. Das erhöht natürlich die Einarbeitungszeit, bietet Usern aber auch zahlreiche Möglichkeiten für den Einsatz.

Wenn du dich ausführlich über passende Software informieren möchtest, findest du im trusted-Test der besten Projektmanagement-Software weitere nützliche Informationen.

Die 3 Artefakte von Scrum

Zu den wichtigsten Werkzeugen für jedes Scrum-Team gehören auch die 3 “Artefakte” von Scrum: Das Product Backlog, Sprint Backlog und das Product Increment.

Die habe ich dir oben schon “in der Praxis” vorgestellt; hier gebe ich dir noch einmal eine kleine Zusammenfassung und alle wichtigen Infos:

Product Backlog

Das Product Backlog ist eine priorisierte Liste mit Anforderungen, die an den Projekt-Outcome gestellt werden. Es ähnelt einer To-do-Liste; allerdings enthält es keine konkreten Aufgaben/Tasks, sondern eine Liste von Anforderungen bzw. Zielen, die das fertige “Produkt” erfüllen muss. Konkrete Aufgaben lassen sich aus diesen Anforderungen ableiten. Einzelne Einträge im Product Backlog werden als “Item” bezeichnet. Diese stehen im Backlog weiter oben, je wichtiger sie sind – und werden dann auch präziser beschrieben und ausgearbeitet.

Sprint Backlog

Das Sprint Backlog konkretisiert die Product Backlog Items zu einer Aufgabenliste, die das Projektteam während eines Sprints zu bearbeiten hat. Die Erarbeitung und Erstellung des Sprint Backlogs erfolgt zu Beginn eines jeden Sprints durch das gesamte Scrum-Team. Das Sprint Backlog ist damit eine ausgewählte Teilmenge der Anforderungen des Product Backlogs mit den einzelnen Tasks und Subtasks, die für die Erfüllung nötig sind.

Product Increment

Das Product Increment steht als vorzeigbares Arbeitsergebnis eines Sprints und ist gleichzeitig ein abgeschlossener Teil des späteren Produktes. Ein Product Increment muss dabei einige weitere Bedingungen erfüllen. Es muss den Stakeholdern bzw. Kunden vorzeigbar sein und als Teilprodukt potenziell auslieferbar sein.

Weitere Werkzeuge für den Scrum-Prozess

Weitere Werkzeuge, Methoden und Tools, die dich beim “Scrummen” unterstützen können, zeige ich dir hier:

Planning Poker

Ich hatte es oben schon einmal kurz angesprochen. Das Planning Poker (oder Scrum Poker) ist eine spielerische Methode zur Aufwandsschätzung und eine meiner Lieblingsmethoden für die Planung. Alle Teammitglieder (“Spieler:innen”) bekommen ein Set aus Spielkarten mit Zahlenwerten in der Fibonacci-Folge (also 0, 1, 2, 3, 5, 8,13 usw.; oft sind auch Karten mit “0,5”, “?” oder “∞” mit dabei).

Im Sprint Planning nutzt dein Team diese Karten, um den Aufwand einer bestimmten Aufgabe zu schätzen.

Also: eine konkrete Aufgabe wird vorgestellt, alle legen ihre Schätzung verdeckt auf den Tisch und decken sie auf Kommando auf. Die Spieler:innen mit der höchsten und der niedrigsten Schätzung müssen nun ihre Einschätzungen begründen. Dann darf das ganze Team diskutieren und versuchen, zu einer gemeinsamen Bewertung zu kommen.

Das Planning Poker ist eine spielerische und effektive Methode, um den Arbeitsaufwand zu schätzen
Das Planning Poker ist eine spielerische und effektive Methode, um den Arbeitsaufwand zu schätzen
Quelle: trusted.de

Es ist kein Muss, Planning Poker zu spielen, wenn du mit deinem Team Aufgaben planst. Für einige Aufgaben ist die Methode auch einfach nicht geeignet, denn je komplexer der Task, desto ungenauer die Schätzungen. Im Umfang begrenzte Aufgaben lassen sich damit aber schon sehr gut einschätzen.

Roman Voting

Es gibt Fragen, die klärt ein Team am besten durch ein einfaches “Ja” oder “Nein”. Nachdem ein Vorschlag ausführlich diskutiert wurde, stimmt jedes Teammitglied mit einem Handzeichen ab. Daumen nach oben bedeutet “Zustimmung”; Ablehnung wird mit einem Daumen nach unten angezeigt. Eine Enthaltung ist theoretisch auch möglich, indem der Daumen waagerecht gehalten wird. Ob du diese Variante zulässt, ist dir überlassen.

Eine Anwendungsmöglichkeit für Roman Voting ist beispielsweise die Entscheidung über einen Optimierungsvorschlag, der im Zuge einer Sprint Retrospective genannt wird.

Roman Voting spart Zeit, ist demokratisch und effektiv. Du solltest es aber nur nutzen, wenn Demokratie auch wirklich das Gebot der Stunde ist. Flache Hierarchien schön und gut, aber in einigen Fällen muss der Scrum Master das letzte Wort haben, um die Prozesse zu schützen.

Burndown-Chart

Die Burndown-Chart ist eine grafische Darstellung zur Veranschaulichung von verbleibender Arbeit im Verhältnis zur angesetzten Projektdauer. Agil arbeitende Teams erkennen so auf einen Blick, ob Deadlines und Fristen eingehalten werden und ob sich Projekte im Soll befinden. Scrum Teams, die in Sprints arbeiten, können so außerdem prüfen, ob einzelne Sprintziele (siehe “Sprint Goal”) erreicht wurden.

Ein Burndown-Chart ist eine simple Möglichkeit, mit der du prüfen kannst, ob sich dein Projekt im Soll befindet
Ein Burndown-Chart ist eine simple Möglichkeit, mit der du prüfen kannst, ob sich dein Projekt im Soll befindet
Quelle: trusted.de

Das Gegenteil ist ein Burnup-Chart, die Auskunft darüber gibt, wie viel Arbeit bereits erledigt worden ist.

Whiteboards und Co.

Whiteboards helfen bei der Visualisierung von Aufgaben, Ideen und Vorschlägen und sollten von Scrum-Teams umfangreich genutzt werden. Office-Teams nutzen hierfür oft einen eigenen Raum (in dem auch die Meetings stattfinden) als “Informationszentrale”. Alle Mitglieder des Teams können sich hier selbstständig informieren und den Fortschritt von Aufgaben einsehen.

Hier ein Beispiel für die Nutzung eines digitalen Whiteboards
Hier ein Beispiel für die Nutzung eines digitalen Whiteboards
Screenshot: trusted.de
Quelle: jamboard.google.com

Remote-Teams haben es naturgemäß nicht ganz so einfach und müssen auf digitale Lösungen ausweichen. Hier gibt es aber viele gute und geprüfte Lösungen, um sich auch über weite Entfernung hinweg auszutauschen. Sowohl Zoom als auch Google Meet und MS Teams integrieren mittlerweile passable Lösungen.

Fazit: Wie nutze ich Scrum für mich und wann stößt es an seine Grenzen?

Wie du siehst, ist Scrum “easy to learn” aber “hard to master”.

Du wirst einiges an Konzeption und Planung brauchen, damit dein Team erfolgreich scrummen kann. Neben den Rollen, Events und Instrumenten spielt vor allem die Mentalität im Team (und im ganzen Unternehmen) eine riesige Rolle.

Gehen wir einmal kurz einen Schritt zurück und werden etwas abstrakter!

Scrum ist eine empirische Arbeitsmethode und basiert auf Erkenntnisgewinn und ständiger Adaption. Das verlangt von allen Beteiligten ein hohes Gespür für Veränderungen, Flexibilität und Mut zur Innovation. Scrum kann nur gelingen, wenn alle Teammitglieder bereits sind, Prozesse zu hinterfragen, selbstständig zu denken und zu handeln. Wenn dein Team das nicht mitbringt, bringt dir leider auch der schönste Guide nichts.

Außerdem solltest du mit den richtigen Erwartungen an die Sache gehen!

Scrum ist kein Wundermittel und nicht für alle Projekte, Branchen, Abteilungen, Teams und Unternehmen geeignet. Wenn du versuchst, die Methode über etwas zu stülpen, für die es einfach nicht gemacht wurde, bringt der Scrum-Prozess mehr Hindernisse als Vorteile.

Sofern die Voraussetzungen in deinem Team gegeben ist, hält dich nun aber nichts mehr davon ab, sofort mit dem “Scrummen” zu beginnen.

Tipps für den Einstieg in die Scrum-Methode

Hier noch ein paar Tipps, die du bei der Einführung von Scrum beherzigen solltest:

Lass nicht den Chef raushängen!

Scrum arbeitet nicht nach einem Top-Down-Prinzip. Es gibt keine “Anweisungen von oben”, die eins zu eins umgesetzt werden müssen. Alle Teammitglieder sind Teil des Organismus; Entscheidungen werden im Team gefällt und Prozesse gemeinsam erarbeitet und angepasst.

Zwar gibt es den Product Owner und den Scrum Master, die eine gesonderte Rolle einnehmen; grundsätzlich sollten sich aber alle Beteiligten dem gemeinsamen Ziel unterordnen und ihre Rolle nicht als “leitend”, sondern als unterstützend verstehen.

Besinne dich auf die Grundwerte von Scrum!

Scrum arbeitet nicht nur nach Prinzipien, sondern verlangt auch einen besonderen Wertekanon, der von allen Teammitgliedern verinnerlicht werden muss. Diese Werte sind für alle verbindlich und die wichtigste Grundlage, auf denen die Scrum-Prinzipien aufbauen:

Openness/Offenheit

Alle Teammitglieder sollen und müssen offen, direkt und gleichberechtigt miteinander kommunizieren. Das schafft Transparenz und ist ein notwendiger Baustein, wenn man auf Top-Down-Hierarchien verzichtet. Scrum kann nur funktionieren, wenn insbesondere in den Meetings (Daily Scrum, Sprint Retrospective) ein reger Austausch herrscht.

Courage/Mut

Mut und Offenheit bedingen einander und sind insofern ein Wertepaar. Manchmal ist die Wahrheit unbequem und nicht einfach zu kommunizieren. Agile Prozesse benötigen aber den Mut aller Teammitglieder, auch weniger positive Aspekte deutlich anzusprechen. Nur so können Veränderungen hin zu einer Optimierung angestoßen werden. Oder anders ausgedrückt: Wenn etwas Mist ist, muss man sagen, dass es Mist ist!

Respect/Respekt

Offenheit und Mut funktionieren besser, wenn alle Beteiligten respektvoll miteinander umgehen und sich gegenseitig achten. Ein respektvoller Umgang beinhaltet dabei auch das Vertrauen in die Kompetenz anderer. Und auch die Unternehmensführung kann hier einen wertvollen Beitrag leisten, indem es dem Projektteam die nötigen Freiheiten gibt, selbstorganisiert zu handeln.

Focus/Fokus

Ein agiles Team benötigt klar definierte Ziele, kurze Iterationen und eine Besinnung auf das aktuell Wesentliche. Zwar gibt der Scrum-Aufbau über Sprints hier schon eine passende Struktur vor, dennoch muss jedes Teammitglied sich auf die anstehenden Aufgaben konzentrieren und Ablenkungen, die eine Zielerreichung gefährden, vermeiden.

Commitment/Hingabe

Commitment ist eine Grundvoraussetzung für selbstorganisiertes Arbeiten. Teammitglieder müssen sich als Teil des Ganzen begreifen, um mit vollem Einsatz das Beste für ein erfolgreiches Projekt geben zu können. Das richtige Engagement ist gleichermaßen eine Hol- und Bringschuld: Unternehmen können Anreize setzen und das Commitment von Mitarbeiter:innen unterstützen. Gleichzeitig müssen die einzelnen Teammitglieder aber auch das Rüstzeug für die benötigte Begeisterung mitbringen.

Achte auf Rollen- und Machtkonflikte!

Scrum basiert einerseits auf flachen Hierarchien, setzt andererseits aber auch auf eine klare Rollenverteilung und definierte Kompetenzen. Das mag auf den ersten Blick paradox wirken, bei genauerer Betrachtung ergeben sich aber etliche Vorteile aus dieser ungleichen Konstellation.

Wichtig ist nur, dass alle Teammitglieder ihre Rolle kennen und auch annehmen.

Scrum-Teams leben von der Zusammenarbeit auf Augenhöhe, dem ständigen Austausch und einer hohen Bereitschaft, Fehler und Hindernisse gemeinsam zu erkennen und zu beseitigen. Dennoch ist es wichtig, dass bestimmte Kompetenzen klar zugeordnet sind.

Egal wie gut geplant: In Projekten kann und wird es immer zu Reibereien und Unstimmigkeiten kommen. Daher ist die Rolle des Scrum Masters so wichtig: Er vermittelt, sorgt für ein positives Arbeitsklima und nimmt Stimmungen auf, um sie im Optimalfall in Produktivität und ein besseres Miteinander umzukehren. Dennoch gilt auch hier wieder die Eigenverantwortung.

Nochmal mit Gefühl: Scrum kann nur erfolgreich sein, wenn alle Beteiligten an einem Strang ziehen!

Lerne aus Fehlern und Erfahrungen!

Wie oben bereits beschrieben, lebt und atmet Scrum die Empirie.

Erfahrungen und Erkenntnisse stehen über Werkzeugen und Methoden. Das ist ein oftmals unterschätzter Faktor und sollte ernst genommen werden. Frei nach dem Motto “Ein Fehler ist es nur, wenn man ihn zweimal macht” funktioniert auch Scrum. Dafür ist es entscheidend, dass alle Beteiligten den Mut aufbringen, Fehler auch als solche anzusprechen.

Denn ihr werdet Fehler machen. Das lässt sich nicht vermeiden und gehört zum Scrum-Prozess dazu.

Setze um, was für dich funktioniert!

Teams merken sehr schnell, welche Scrum-Praktiken und Arbeitsweisen für sie funktionieren. Hier hilft eine ehrliche und offene Analyse der erzielten Ergebnisse und Prozesse. Dafür gibt es die Sprint Retrospective.

Denn nicht alle Scrum-Praktiken eignen sich auch tatsächlich für jedes Team und Projekt gleichermaßen. Es gibt zahlreiche Hybrid-Varianten, die klassische und agile Methoden mischen und so eine optimale Kombination beider Ansätze vereinen.

Wichtig ist nur, dass Elemente, die funktionieren, auch wirklich in den Arbeitsalltag integriert und übernommen werden.

Daraus ergibt sich direkt auch mein nächster Tipp:

Passe an, was für dich nicht funktioniert!

Scrum ist ein Rahmenwerk, schreibt dir aber nicht vor, wie du den Rahmen genau zu füllen hast. Es ist ein Fehler, sich sklavisch an bestimmte Vorgaben zu halten, erst recht, wenn diese Vorgaben für dich und dein Team nicht funktionieren!

Beispiel Sprint: wöchentliche Sprints bedeuten auch einen gewissen Aufwand in der Planung. Sehr kleine Teams können ein Sprint-Intervall je nach Projekt auch ausdehnen und so die Meetingdichte entschlacken.

Es gibt zwar einige Scrum-Expert:innen, die davor warnen, nur Teilaspekte von Scrum umzusetzen.

Aber am Ende ist wichtig, dass die Projektarbeit funktioniert, nicht dass du einen Preis für den besten Scrum-Prozess gewinnst. Wenn also ein Mix aus klassischen und agilen Konzepten in deinem Team funktioniert: go for it!

Plane nicht zu viel parallel!

Ganz oder gar nicht! Gerade große Unternehmen neigen dazu, Mitarbeiter:innen für mehrere Scrum-Teams zu verplanen. Das kann an den Kompetenzen liegen, die benötigt werden, oder weil die einzelnen Projekte nur einen geringen Umfang haben.

Das widerspricht aber den Scrum-Werten, die unter anderem einen vollen Fokus aller Teammitglieder verlangen. Ein weiterer Punkt ist die Arbeitszeit, denn die ist bekanntlich endlich. Mehrere Daily Scrums, Reviews und Abschlussmeetings gehen zulasten der Produktivität und verschleppen Ergebnisse.

Scrum Ressourcen

Du hast in meinem Guide vielleicht festgestellt, dass Scrum seine eigene Sprache hat. Hier ist das Wörterbuch dazu:

Kleines Scrum-Lexikon

Product Owner

Der Product Owner ist für die erfolgreiche Produktentwicklung verantwortlich und ist gleichzeitig die Schnittstelle zwischen Scrum-Team und Stakeholdern/Kund:innen. Er sorgt dafür, dass die Produktvision anhand der Kundenvorgaben umgesetzt wird.

Product Backlog

Das Product Backlog ist eine priorisierte Liste mit Anforderungen, die an das fertige Produkt gestellt werden. Alle geforderten Produkteigenschaften sind hier verständlich hinterlegt, sodass daraus alle notwendigen Aufgaben abgeleitet werden können.

Product Increment

Das Product Increment steht am Ende eines Sprints als fertiges Teilergebnis des Produktes und muss bestimmte Kriterien erfüllen. Ein Increment soll gemäß der DoD abgeschlossen und damit den Kunden oder Auftraggebern vorzeigbar und einsatzfähig sein. Der Product Owner kann entscheiden, ob ein Product Increment bereits an den Kunden ausgeliefert wird.

Sprint

Ein Sprint ist der Arbeitszyklus (oder Iteration) eines Scrum-Teams, innerhalb dessen ein Teilabschnitt der Produktentwicklung erledigt werden muss. Der übliche Zeitraum erstreckt sich von 1 bis maximal 4 Wochen und sollte diese Marke nur in Ausnahmefällen und sehr kleinen Teams überschreiten.

Daily Scrum

Der Daily Scrum ist ein täglich stattfindendes Meeting des Scrum-Teams, in dem anstehende Aufgaben besprochen und zwischen den Team-Mitgliedern synchronisiert werden. Die Timebox für den Daily Scrum beträgt 15 Minuten und sollte nicht länger dauern.

Sprint Backlog

Das Sprint Backlog ist die Arbeitsgrundlage für den jeweiligen Sprint und enthält eine Teilmenge der im Product Backlog formulierten Produkt-Anforderungen. Das Sprint Backlog überträgt diese Anforderungen in konkrete Aufgaben und To-Dos. Die übliche Darstellung eines Sprint Backlogs erfolgt in einem Kanban- bzw. Scrum-Board.

Sprint Review

Die Sprint Review ist ein Meeting am Ende eines Sprints und dient zur Vorstellung der Arbeitsergebnisse. Je nach Anforderung nimmt der Product Owner die erreichten Ergebnisse ab. Bei Bedarf können aber auch Stakeholder anwesend sein, um den Projektfortschritt nachzuvollziehen und die fertigen Product Increments zu begutachten.

Sprint Retrospective

Die Retrospektive ist ein Meeting des Scrum-Teams zum Sprint-Abschluss und gibt Gelegenheit, Schwierigkeiten und Probleme zu besprechen. Diese Fehleranalyse soll dazu beitragen, dass der darauf folgende Sprint optimaler verläuft.

Scrum Master

Der Scrum Master fungiert als Coach und Berater und sorgt für die Einhaltung der Scrum-Prinzipien. Außerdem tritt er als Team-interner Mediator auf, vermittelt bei Kommunikationsschwierigkeiten und sorgt für ein optimales Teamwork während jeder Projektphase.

Scrum Team

Das Team setzt sich üblicherweise aus 1-8 Developern bzw. Produktentwickler:innen zusammen. Während früher das Entwicklerteam als Team-im-Team behandelt wurde, gibt es nach heutigem Standard nur noch ein gesamtes Scrum-Team. Hier gehören also sowohl der Scrum Master als auch der Product Owner dazu. Wichtig: Die Developer sollten über alle benötigten Kompetenzen für eine erfolgreiche Projektarbeit verfügen und externen Input nur im Einzelfall hinzuziehen.

Scrum-Checkliste

Diese Checkliste ist eine übersichtliche Zusammenfassung meines Ratgebers. Sie soll dir dabei helfen, Scrum einzuführen und dein erstes Scrum-Projekt erfolgreich durchzuführen. Orientiere dich gerne daran, wenn du dein erstes Projekt mit Scrum planst:

  • Agiles Projektmanagement als neue Arbeitsweise etablieren
    • Ziele klar definieren (Was will ich mit Scrum erreichen?)
    • Zeithorizont planen (Wann will ich mit Scrum starten?)
    • Agiles “Mindset” etablieren und ins Team tragen
  • Bevor es losgeht
    • Product Owner bestimmen
    • Scrum Master einsetzen
    • Developer-Team zusammenstellen
    • Sprintzyklus festlegen (1 bis 4 Wochen)
    • Meeting-Routine festlegen (Daily Scrum – Wer, wann, wo und wie?)
    • Termine festlegen (Sprint Planning, Sprint Review, Sprint Retrospective)
    • Tools bereitstellen (PM-Software, Videokonferenz-Software und Co.)
    • Ggf. Workshop oder Schulung mit dem Team durchführen
  • Projektvorbereitung
    • Stakeholder identifizieren
    • Mit Stakeholdern Projektziele/Vision definieren
    • Budget und Ressourcen planen
    • Product Backlog anlegen
  • Sprint Planning
    • Product Backlog Items für Sprint vorbereiten
    • Definition of Ready fixieren
    • Sprintziele im Team festlegen (ggf. diskutieren)
    • Abhängigkeiten, Anforderungen und Risiken definieren
  • Taskboard
    • Taskboard/Kanban-Board anlegen
    • Aufgaben aus dem Sprint Planning anlegen
    • Zuständigkeiten verteilen
    • Loslegen!

Scrum Guide 2020 (Download)

Was ist der Scrum Guide?

Der Scrum Guide ist nicht nur eine Erklärung, was Scrum eigentlich ist und in welchen Bereichen es sich gut einsetzen lässt. Vielmehr ist es eine Schritt-für-Schritt-Anleitung zur erfolgreichen Einführung von Scrum in deinem Unternehmen. Hier erfährst du alles zu den Voraussetzungen, benötigten Tools und Hilfsmitteln und auf welche Punkte du besonders acht geben musst, wenn die Implementierung von Scrum gelingen soll.

Hier findest du den aktuellen Scrum-Guide der Scrum-Erfinder Ken Schwaber und Jeff Sutherland, zuletzt aktualisiert im Jahr 2020.

Scrum FAQ

Was ist Scrum?

Scrum ist ein Framework für agiles Projektmanagement. Scrum beruht dabei auf kurzen iterativen Arbeitszyklen, enger Kommunikation und einer ständigen Analyse von Prozessen und Ergebnissen.

Was bedeutet Scrum eigentlich?

Scrum ist ein Begriff aus dem Rugby-Sport und bedeutet “Gedränge”. Damit spielt Scrum den Umstand an, dass Teams eng miteinander arbeiten und kommunizieren müssen, um flexibel und dynamisch auf komplexe Problemstellungen reagieren zu können.

Was sind die Regeln von Scrum (kurz und bündig)?

Scrum benötigt für die erfolgreiche Umsetzung eine transparente Kommunikation aller Teammitglieder. Wichtig hierfür sind regelmäßige Meetings (Daily Scrum), eine hohe Eigenverantwortung des Scrum Teams, selbstständiges Arbeiten und ein gemeinsames Verständnis des Projektzieles. Außerdem sollten alle Rollen strikt eingehalten werden und Teammitglieder ihre Zuständigkeiten kompetent ausfüllen.

Ist Scrum als Methode eigentlich zeitgemäß?

Die Antwort auf die Frage, ob Scrum für ein Projektteam sinnvoll ist, ist keine Sache von modern oder altmodisch. Vielmehr steht und fällt die Entscheidung mit der Art der Problemstellung, die ein Projektteam zu lösen hat. Scrum eignet sich hervorragend für komplexe Herausforderungen, bei denen bekannte und routinierte Praktiken und Vorgehensweisen nicht zum Erfolg führen. Insofern ist Scrum insbesondere im Umfeld neuer Technologien und Anwendungen einer klassischen Arbeitsweise vorzuziehen.

Was ist der Unterschied zwischen Scrum und Kanban?

Kanban ist im Wesentlichen ein Framework, das Teams im Aufgabenmanagement durch die Visualisierungen einzelner Tasks unterstützt. So sind Bearbeitungsstand und Zuständigkeit jederzeit transparent und alle Teammitglieder auf demselben Stand. Im Gegensatz dazu beruht Scrum auf festen Prinzipien und Methoden, mit deren Hilfe Projektteams ihre Arbeit strukturieren und organisieren können. So können auch komplexe (einfach gesagt unbekannte) Problemstellungen gelöst werden. Ungeachtet dessen nutzen auch Scrum-Teams im Aufgabenmanagement häufig Kanban-Boards.

Änderungshistorie

19.04.2024
Scrum - Ratgeber

trusted hat den großen Scrum-Ratgeber erstellt. Unser Redakteur Phillip zeigt dir hier alles, was du zum Thema wissen musst! Du hast Fragen oder hast Fehler oder Missverständnisse entdeckt? Dann melde dich doch direkt bei uns unter [email protected]!

Phillip Roth
trusted-Experte für Projekte & Kommunikation
Phillip Roth
trusted-Experte für Projekte & Kommunikation

Phillip ist Teil der Redaktion von trusted. Nach beruflichen Stationen als Vertriebler in großen Unternehmen kennt er sich gut mit den Anforderungen im Marketing und Projektmanagement aus. Mit dieser Erfahrung testet er u.a. PM-Tools für trusted.de

Babbel Bewertungen

4.5
918.106 Bewertungen
davon sind
918.006 Bewertungen
aus 3 anderen Quellen

Bewertungsquellen

203.579 Kunden bewerten auf iTunes durchschnittlich mit 4.6 von 5 Punkten (Stand: 07.03.2022)
203.579 Kunden bewerten auf iTunes durchschnittlich mit 4.6 von 5 Punkten (Stand: 07.03.2022)
203.579 Kunden bewerten auf iTunes durchschnittlich mit 4.6 von 5 Punkten (Stand: 07.03.2022)
trusted