Agiles Projektmanagement mit Scrum und Kanban: So arbeiten moderne Softwareteams

Was ist agiles Projektmanagement und welche Rolle spielen Scrum und Kanban?

Agiles Projektmanagement ist eine Arbeitsweise, bei der Softwareteams in kurzen Zyklen liefern und laufend Feedback einholen, statt einem starren Gesamtplan zu folgen. Das Agile Manifest legt die Werte fest. Scrum macht daraus ein schlankes Rahmenwerk mit klaren Verantwortlichkeiten, Events und Artefakten. Kanban steuert dagegen den Arbeitsfluss.

Kunden aus meinen Webdesign und E-Commerce Projekten fragen mich oft, warum Entwickler ständig von Sprints und Backlogs sprechen. Ich arbeite seit 2012 im Online Marketing und sitze regelmäßig in solchen Runden. In diesem Ratgeber stütze ich die Theorie auf offizielle Quellen und die Praxis auf meine eigene Erfahrung. Einen Vergleich von Tools spare ich bewusst aus, denn dazu gibt es einen eigenen Artikel.

Warum scheitert das klassische Wasserfallmodell so oft an Software?

Im Wasserfallmodell läuft die Arbeit in fester Reihenfolge: Anforderungen, Entwurf, Umsetzung, Test und Auslieferung. Auf dem Papier wirkt das ordentlich. Allerdings ändern sich Anforderungen bei Software mitten im Projekt. Der Kunde sieht den ersten Bildschirm und weiß plötzlich, was er eigentlich will. Zudem bewegt sich der Markt, und ein Wettbewerber bringt eine neue Funktion heraus.

Folglich arbeitet ein Wasserfallteam monatelang und zeigt das Produkt erst am Ende. Ein missverstandenes Detail zu korrigieren, kostet dann viel Geld. Das Muster, das ich am häufigsten sehe, ist dann simpel: Der vertragliche Umfang ist erfüllt, das eigentliche Bedürfnis der Nutzer aber nicht. Kurz gesagt liegt das Problem nicht in der Planung selbst. Es liegt in der Annahme, dass Unsicherheit ausbleibt.

Trotzdem ist Wasserfall nicht immer falsch. Bei festen, regulierten Vorhaben ohne Änderungen funktioniert es weiterhin. Die meisten Web und Mobile Produkte gehören allerdings nicht dazu.

Agiles Projektmanagement antwortet darauf so: Wenn Sie Unsicherheit nicht beseitigen können, zerlegen Sie sie in kleine Stücke. Sie liefern in kurzen Zyklen und holen am Ende jedes Zyklus echtes Feedback ein. Somit zeigt sich eine falsche Annahme nach wenigen Wochen statt nach Monaten. Auch die Kosten der Korrektur bleiben dadurch klein.

Welche vier Werte vertritt das Agile Manifest?

Siebzehn Softwareentwickler unterzeichneten 2001 in Snowbird im US Bundesstaat Utah das Agile Manifest. Konkret enthält der Text vier Wertsätze. Jeder Satz schätzt die linke Seite höher als die rechte. Die rechte Seite lehnt er dennoch nicht völlig ab.

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge.
• Funktionierende Software mehr als umfassende Dokumentation.
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung.
• Reagieren auf Veränderung mehr als das Befolgen eines Plans.

Beachten Sie: Das Manifest ist keine Methode. Es liefert weder einen Meetingkalender noch Rollenbeschreibungen. Deshalb frage ich jedes Team, das sich agil nennt, sofort nach: mit welchem Rahmenwerk? Die Antwort lautet meist Scrum, Kanban oder eine Mischung aus beiden.

Wie zeigen sich die zwölf agilen Prinzipien im Arbeitsalltag?

Hinter den Werten stehen zwölf Prinzipien. Auswendig lernen müssen Sie sie nicht. Einige davon prägen den Alltag allerdings direkt. Zum Beispiel stellt das erste Prinzip die Zufriedenheit des Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software an die Spitze. Ein anderes nennt funktionierende Software das wichtigste Fortschrittsmaß.

• Liefern Sie funktionierende Software regelmäßig, alle paar Wochen bis alle paar Monate, bevorzugt im kürzeren Takt.
• Fachleute und Entwickler arbeiten während des Projekts täglich zusammen.
• Das Gespräch von Angesicht zu Angesicht ist der effizienteste Weg, Informationen zu teilen.
• Einfachheit, also die Kunst, unnötige Arbeit zu vermeiden, ist essenziell.
• In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten an.

Für agiles Projektmanagement ist mein Lieblingsprinzip deshalb die Einfachheit. Denn in Kundenprojekten verschlingt nichts so viel Zeit wie Funktionen, die niemand nutzt. Ein gutes agiles Team fragt daher zuerst: Was passiert, wenn wir das gar nicht bauen?

Was ist Scrum laut Scrum Guide?

Der Scrum Guide ist ein kurzes Dokument von Ken Schwaber und Jeff Sutherland. Er enthält die einzige offizielle Definition von Scrum. Der Guide beschreibt Scrum als leichtgewichtiges Rahmenwerk, das Menschen, Teams und Organisationen hilft, durch adaptive Lösungen für komplexe Probleme Wert zu schaffen. Anders gesagt: Scrum ist absichtlich unvollständig. Die Lücken füllt das Team mit eigenen Praktiken.

Scrum basiert auf Empirie und schlankem Denken. Empirie heißt: Wissen entsteht aus Erfahrung, und Entscheidungen folgen dem, was Sie beobachten. Schlankes Denken verlangt, Verschwendung zu reduzieren und sich auf das Wesentliche zu konzentrieren. Zusammen machen beide Wurzeln agiles Projektmanagement evidenzbasiert statt spekulativ.

Die Ausgabe von 2020 ist weniger vorschreibend als frühere Versionen. Konkret ersetzte sie den Begriff Development Team durch Developers und beschreibt das Team als selbstmanagend. Außerdem betont sie, dass Scrum für jede komplexe Arbeit taugt, nicht nur für Software.

Was sind die drei Säulen und fünf Werte von Scrum?

Der Guide stützt die Empirie auf drei Säulen: Transparenz, Überprüfung und Anpassung. Transparenz bedeutet, dass alle Beteiligten den Prozess sehen können. Überprüfung heißt, Artefakte und den Fortschritt zu den Zielen häufig zu kontrollieren. Anpassung bedeutet, Prozess oder Produkt sofort zu korrigieren, sobald Sie eine Abweichung erkennen.

Zudem nennt der Guide fünf Werte: Commitment, Fokus, Offenheit, Respekt und Mut. Das klingt zunächst abstrakt. In der Praxis hat es allerdings sehr konkrete Folgen. Mut heißt zum Beispiel, ein schwieriges Problem mitten im Sprint anzusprechen. Offenheit bedeutet, früh zu sagen: Das schaffen wir nicht.

Meine Beobachtung aus Projekten: Teams, die die Werte an die Wand hängen, schlechte Nachrichten im Meeting aber verschweigen, übernehmen nur den Kalender von Scrum. Daher erkennen Sie die Reife eines Teams weniger an seinen Events als daran, wie früh es über Probleme spricht.

Welche Verantwortlichkeiten gibt es in einem Scrum Team?

Der Scrum Guide definiert drei Verantwortlichkeiten. Laut Guide besteht ein Scrum Team typischerweise aus zehn oder weniger Personen, weil kleinere Teams besser kommunizieren. Es gibt keine Unterteams und keine Hierarchien.

Diese Trennung halte ich daher für den wichtigsten Punkt, wenn agiles Projektmanagement funktionieren soll. Denn in vielen Unternehmen verkommt der Product Owner zum Vermittler ohne echte Befugnis. Der Guide sagt dagegen klar, dass der Product Owner eine einzelne Person ist und die Organisation seine Entscheidungen respektieren muss.

Ist der Product Owner dasselbe wie ein Projektleiter?

Nein, es handelt sich um verschiedene Rollen. Ein klassischer Projektleiter steuert Umfang, Zeit und Budget und verteilt Aufgaben. In Scrum verteilt niemand Aufgaben. Stattdessen planen die Developers die Arbeit untereinander. Der Product Owner beantwortet das Was und das Warum, nicht das Wie.

Deshalb kann es schiefgehen, einen früheren Projektleiter direkt zum Product Owner zu machen. Diese Person muss Geschäft und Kunden kennen und Prioritäten selbst entscheiden dürfen. Ebenso ist der Scrum Master kein Managerposten, sondern eine dienende Form der Führung.

Auf Kundenseite erlebe ich etwas Ähnliches. Wenn bei einem Webprojekt unklar ist, wer entscheidet, bekommt eine Sprintdemo fünf Meinungen von fünf Personen. Also kläre ich zu Beginn jedes Projekts zuerst die Frage: Wer hat das letzte Wort?

Was ist ein Sprint und warum dauert er höchstens einen Monat?

Der Sprint ist das Herz von Scrum. Laut Scrum Guide ist ein Sprint ein Event mit fester Länge von einem Monat oder weniger. Direkt nach dem Ende eines Sprints beginnt der nächste. Alle anderen Events finden innerhalb des Sprints statt.

Warum so kurz? Weil längere Sprints das Sprintziel veralten lassen, die Komplexität erhöhen und das Risiko steigern. Ein kurzer Zyklus garantiert mindestens einmal im Monat echtes Feedback. Außerdem nehmen Sie während des Sprints keine Änderungen vor, die das Sprintziel gefährden, und senken nicht die Qualität.

In der Praxis sind zweiwöchige Sprints sehr verbreitet, obwohl der Guide keine genaue Länge vorgibt. Für die Kalenderplanung nutze ich den Tage Rechner, um Sprintenden mit Feiertagen abzugleichen. So landet ein Sprint Review nie überraschend auf einem Brückentag.

Welche Fragen beantwortet das Sprint Planning?

Das Sprint Planning eröffnet den Sprint. Der Guide begrenzt es bei einem einmonatigen Sprint auf höchstens acht Stunden; bei kürzeren Sprints fällt es meist kürzer aus. Es behandelt drei Themen:

1. Warum ist dieser Sprint wertvoll? Der Product Owner erklärt den Wert, und das Team einigt sich auf ein Sprintziel.
2. Was lässt sich in diesem Sprint erledigen? Die Developers wählen Einträge aus dem Product Backlog anhand ihrer bisherigen Leistung und Kapazität.
3. Wie erledigen wir die gewählte Arbeit? Die Developers zerlegen jeden Eintrag meist in Stücke von einem Tag oder weniger.

Aus diesen Antworten entsteht das Sprint Backlog. Mein Rat: Formulieren Sie das Sprintziel in einem einzigen Satz. Zum Beispiel: „Kunden gelangen fehlerfrei vom Warenkorb zur Zahlung.“ Dann prüfen Sie jede neue Anfrage mitten im Sprint gegen genau diesen Satz.

Wie bleibt das Daily Scrum in 15 Minuten nützlich?

Das Daily Scrum ist ein Event von 15 Minuten für die Developers, jeden Arbeitstag zur gleichen Zeit am gleichen Ort. Es dient dazu, den Fortschritt zum Sprintziel zu überprüfen und das Sprint Backlog bei Bedarf anzupassen. Vor allem ist es kein Statusbericht für Vorgesetzte.

Das alte Schema „gestern, heute, Hindernisse“ ist im Guide von 2020 nicht mehr vorgeschrieben. Das Team wählt jede Struktur, solange der Fokus auf dem Ziel liegt. Zudem spart es allen Zeit, technische Detaildiskussionen auf die Zeit nach dem Meeting zu verlegen.

• Führen Sie das Meeting vor dem Board und sprechen Sie über die Arbeit selbst.
• Besprechen Sie zuerst den Eintrag, der am weitesten vom Sprintziel entfernt ist.
• Taucht ein Hindernis auf, benennen Sie, wer es löst, statt es live zu lösen.
• Macht die Anwesenheit einer Führungskraft daraus eine Berichtsrunde, sprechen Sie das offen an.

Kurz gesagt signalisiert jedes Daily Scrum über 15 Minuten ein Planungsproblem. Statt das Meeting zu verlängern, öffnen Sie direkt danach eine kurze Arbeitsrunde mit den zwei oder drei Beteiligten. Alle anderen kehren dann an ihre Arbeit zurück.

Worin unterscheiden sich Sprint Review und Sprint Retrospektive?

Beide Events finden am Ende des Sprints statt, prüfen aber verschiedene Dinge. Das Sprint Review betrachtet das Produkt. Die Retrospektive betrachtet dagegen die Arbeitsweise des Teams. Bei einem einmonatigen Sprint begrenzt der Guide das Review auf vier Stunden und die Retrospektive auf drei Stunden.

Zunächst ist das Sprint Review eine Arbeitssitzung, keine Präsentation. Das Team zeigt, was es gebaut hat, die Stakeholder geben Feedback, und gemeinsam aktualisieren alle das Product Backlog. Bei Webprojekten öffne ich echte Seiten, oft die laufende Testumgebung. Somit beurteilt der Kunde das Produkt am Bildschirm statt auf einer Folie.

Die Retrospektive bleibt intern. Das Team betrachtet Personen, Interaktionen, Prozesse, Werkzeuge und seine Definition of Done. Danach wählt es die hilfreichsten Verbesserungen und nimmt sie möglichst ins nächste Sprint Backlog auf. Sonst taucht alle zwei Wochen dieselbe Beschwerde wieder auf.

Was sichern die drei Scrum Artefakte und ihre Commitments?

Der Scrum Guide definiert drei Artefakte und verknüpft jedes mit einem Commitment. Diese Commitments stärken Transparenz und Fokus. Die Tabelle fasst den Zusammenhang zusammen.

Am meisten unterschätzt ist die Definition of Done. Laut Guide darf ein Eintrag, der sie nicht erfüllt, weder Teil des Increments sein noch im Review erscheinen. Bei Webprojekten umfasst meine Definition meist einen Mobiltest, einen Ladezeittest, Grundlagen der Barrierefreiheit und zentrale SEO Prüfungen. Konkret gilt eine Seite für mich erst als fertig, wenn ich ihre Tags mit dem Meta Tag Generator geprüft habe.

Wie ordnen und verfeinern Sie das Product Backlog?

Das Product Backlog ist eine geordnete Liste von allem, was das Produkt verbessert. Für diese Ordnung ist der Product Owner verantwortlich. Allein schreiben muss er die Liste aber nicht, denn Input kommt vom Team und von Stakeholdern.

Refinement heißt, Einträge in kleinere, klarere Stücke zu zerlegen und Beschreibung, Reihenfolge und Größe zu ergänzen. Der Guide definiert dafür kein eigenes Event, sondern beschreibt eine laufende Tätigkeit. In der Praxis reservieren die meisten Teams trotzdem eine kurze wöchentliche Runde.

Beim Ordnen stelle ich drei Fragen. Wie viel Wert schafft der Eintrag? Wie viel Risiko baut er ab? Macht er den Weg für andere Arbeit frei? Zum Beispiel kommt in einem E-Commerce Projekt der Checkout vor dem Blogmodul, weil dort das messbare Conversion Ziel liegt. Mein Artikel zu Online Marketing KPIs liefert dafür passende Kennzahlen.

Was ist Kanban und worin unterscheidet es sich von Scrum?

Kanban ist eine Methode, die den Arbeitsfluss sichtbar macht und die Menge paralleler Arbeit (WIP) begrenzt. Der Kanban Guide nennt drei Kernpraktiken: den Workflow definieren und visualisieren, Arbeit im Workflow aktiv steuern und die Workflow Definition verbessern. Feste Sprints, Pflichtrollen oder Events kennt Kanban nicht.

Zusammengefasst liefert Scrum einen Rhythmus, Kanban optimiert den Fluss. Daher sehen Sie beide besser als Antworten auf unterschiedliche Probleme statt als Konkurrenten.

Warum macht ein WIP Limit das Team schneller?

Weniger gleichzeitig zu tun, klingt zunächst langsamer. In Wirklichkeit passiert das Gegenteil. Ein Entwickler, der fünf Aufgaben parallel beginnt, verliert ständig Zeit durch Kontextwechsel und beendet keine davon. Ein WIP Limit macht die Regel „erst fertig machen, dann neu anfangen“ für alle sichtbar.

Der Kanban Guide hebt vier Flusskennzahlen hervor: Work in Progress, Durchsatz, Alter der Arbeitseinheit und Durchlaufzeit. Diese Kennzahlen beschreiben den tatsächlichen Fluss, keine Schätzung. Folglich beantworten Sie die Frage „Wann ist das fertig?“ anhand historischer Daten.

Ich achte vor allem auf das Alter der Arbeit. Steht eine Karte tagelang in derselben Spalte, klemmt dort etwas. Nehmen Sie diese Karte im nächsten Daily Scrum als erstes Thema, dann lösen Sie das Problem meist, bevor es wächst.

Wann lohnt sich Scrumban oder ein hybrides Modell?

Viele Teams nutzen weder reines Scrum noch reines Kanban. Sie behalten den Sprintrhythmus und ergänzen das Board um WIP Limits. In der Praxis heißt diese Mischung oft Scrumban. Auch die Scrum und die Kanban Community veröffentlichen Hinweise zur gemeinsamen Nutzung.

• Das Team entwickelt neue Funktionen und bearbeitet zugleich dringende Supportanfragen.
• Mitten im Sprint kommt ständig Arbeit hinzu, also bricht das Sprintziel häufig.
• Das Team beendet jeden Sprint mit vielen halbfertigen Einträgen.
• Ein Produkt in der Wartungsphase braucht keine großen Planungsrunden mehr.

Andererseits darf ein Hybrid keine Ausrede sein. Manche Teams, die von ihrer eigenen agilen Variante sprechen, haben schlicht die Retrospektive gestrichen. Deshalb empfehle ich, schriftlich festzuhalten, welche Praxis Sie weglassen und warum.

Welche Fehler bremsen agiles Projektmanagement am häufigsten?

Die Fehler, die ich über die Jahre gesehen habe, ähneln sich stark. Der größte: agiles Projektmanagement auf dem Papier einführen und in Wahrheit weiter wie ein Wasserfallteam arbeiten. Hier die Fehler, die mir am häufigsten begegnen:

1. Statt eines funktionierenden Increments einen Bericht „zu 80 Prozent fertig“ vorlegen.
2. Die Rolle des Product Owners an jemanden ohne Entscheidungsbefugnis vergeben.
3. Maßnahmen aus der Retrospektive nie in einen Sprint aufnehmen.
4. Velocity nutzen, um die Leistung verschiedener Teams zu vergleichen.
5. Ohne schriftliche Definition of Done starten.
6. Das Daily Scrum in eine Berichtsrunde für Vorgesetzte verwandeln.

Der vierte Fehler schadet besonders. Denn Teams beginnen, ihre Schätzungen aufzublähen, und die Zahl verliert ihre Aussagekraft. Kurz gesagt ist eine Kennzahl ein Lernwerkzeug und kein Strafwerkzeug.

Sind User Stories und Story Points in Scrum Pflicht?

Nein, beides kommt im Scrum Guide nicht vor. Eine User Story beschreibt einen Bedarf aus Sicht der Nutzer: „Als Kunde möchte ich meine Bestellung verfolgen, damit ich den Liefertermin kenne.“ Story Points sind eine Einheit, um die relative Größe von Arbeit zu schätzen. Beide sind beliebte ergänzende Praktiken, aber keine Regeln.

Diese Unterscheidung ist deshalb wichtig. Manche Teams verbringen die halbe Planungsrunde mit Punktediskussionen und halten das für Scrum. Der Guide verlangt allerdings nur, dass Einträge eine Größenangabe tragen. Wie Sie messen, entscheidet das Team. Kleidergrößen, Schätzungen in Tagen oder das bloße Zählen von Einträgen funktionieren ebenso.

Mein Rat: Machen Sie aus der Schätzung keine Verhandlung. Sie soll dem Team zeigen, was es in einem Sprint realistisch schafft. Ergänzen Sie außerdem Akzeptanzkriterien für jede Story. Dann klären Sie die Frage „fertig oder nicht“ bereits im Planning und nicht erst im Review.

Wie setzen verteilte Teams die Scrum Events um?

Der Scrum Guide verlangt keine Präsenz, also nutzen verteilte Teams dasselbe Rahmenwerk. Allerdings entsteht Transparenz im Homeoffice nicht von selbst. Sie müssen sie bewusst schaffen: mit einem gemeinsamen digitalen Board, einem schriftlichen Sprintziel und Entscheidungen, die alle wiederfinden.

• Legen Sie das Daily Scrum auf eine feste Uhrzeit, in der sich die Zeitzonen überschneiden.
• Zeigen Sie im Sprint Review das laufende Produkt per Bildschirmfreigabe statt Folien.
• Bieten Sie in der Retrospektive anonyme Notizen an, damit auch stille Mitglieder zu Wort kommen.
• Schreiben Sie Entscheidungen in den Backlog Eintrag, statt sie im Chat liegen zu lassen.

Meine Kunden sitzen zudem oft in verschiedenen Städten. Deshalb schließe ich jedes Review mit einem kurzen Videocall und einer schriftlichen Zusammenfassung ab. So erhalten auch Stakeholder, die nicht dabei waren, dieselben Informationen.

Wie passen Sie Scrum an Agentur und Kundenprojekte an?

Agiles Projektmanagement sieht in Kundenprojekten also anders aus als in internen Produktteams, weil Budget und Termin oft im Vertrag stehen. Den Geist von Scrum können Sie trotzdem bewahren. In meinen Webdesign Projekten fixiere ich die Priorität statt des Umfangs. Somit sind die wertvollsten Seiten und Abläufe in den ersten Sprints fertig.

Am Ende jedes Sprints zeige ich dem Kunden eine laufende Testumgebung. Dann beurteilt er eine funktionierende Seite und keine Designdatei. Die Designphase folgt meinem Figma Prozess, und die Entwicklung baut auf freigegebenen Screens auf.

Kommt eine Änderung des Umfangs, streite ich nicht. Stattdessen frage ich, welchen Backlog Eintrag die neue Arbeit ersetzen soll. Folglich bleibt das Budget gleich, nur die Reihenfolge ändert sich. Genau das ist Zusammenarbeit mit dem Kunden statt Vertragsverhandlung.

Wie skaliert Scrum, wenn das Team wächst?

Wird ein Team zu groß, empfiehlt der Scrum Guide, es in mehrere zusammenhängende Scrum Teams aufzuteilen, die sich auf dasselbe Produkt konzentrieren. Diese Teams teilen ein Produktziel, ein Product Backlog und einen Product Owner. Skalierungsframeworks wie Nexus, LeSS oder SAFe liegen außerhalb des Guides.

Bei großen Unternehmenswebsites beeinflusst die Teamaufteilung auch die Architektur. Jedes Team braucht eine Codebasis, die es unabhängig ausliefern kann. Darüber schreibe ich in meinem Artikel zu Micro Frontends. Teamstruktur und Softwarearchitektur spiegeln einander, also planen Sie beide gemeinsam.

Mein Rat: Stellen Sie zuerst sicher, dass ein einzelnes Team wirklich gut funktioniert, bevor Sie ein Skalierungsframework wählen. Sonst verschieben Sie das Chaos nur auf ein größeres Diagramm.

Woran erkennen Sie, ob agiles Projektmanagement wirkt?

Eine einzelne Zahl reicht dafür allerdings nicht. Auf der Scrum Seite sind erreichte Sprintziele und regelmäßig nutzbare Increments die zentralen Signale. Auf der Kanban Seite zählen die Trends bei Durchlaufzeit und Durchsatz. Allerdings sind all das Prozesskennzahlen.

Die eigentliche Frage lautet, ob die gelieferte Software Geschäftsergebnisse bewegt. Hat der neue Checkout zum Beispiel die Conversion Rate verändert? Deshalb verknüpfe ich das Teamboard mit Geschäftskennzahlen. Mein Artikel zu conversionorientiertem Webdesign ist dafür ein guter Einstieg.

• Prozess: erreichte Sprintziele, Durchlaufzeit, Alter der Arbeit.
• Qualität: Fehler im Livesystem, zurückgerollte Releases.
• Wert: Conversion, Zufriedenheit der Nutzer, weniger Supportanfragen.

Kurz gesagt: Sehen die Prozesszahlen gut aus und die Wertzahlen schlecht, läuft das Team schnell in die falsche Richtung.

Wie startet ein Team mit Scrum?

Für den Einstieg brauchen Sie kein großes Schulungsprogramm. Lesen Sie zunächst den Scrum Guide gemeinsam im Team; er ist ein kurzes Dokument. Dann gehen Sie in kleinen Schritten vor:

1. Benennen Sie einen Product Owner und halten Sie seine Entscheidungsrechte schriftlich fest.
2. Ordnen Sie das erste Product Backlog und zerlegen Sie die obersten Einträge in kleine Stücke.
3. Schreiben Sie die Definition of Done auf eine Seite.
4. Starten Sie mit einem zweiwöchigen Sprint und führen Sie alle Events vollständig durch.
5. Entscheiden Sie nach drei Sprints in der Retrospektive, was Sie ändern.

Bleiben Sie nicht an der Toolwahl hängen, denn den ersten Sprint können Sie sogar an einer Wand mit Karten steuern. Weitere Artikel finden Sie in der Kategorie Software. Wenn Sie Unterstützung beim Aufbau von Team und Prozess wünschen, schreiben Sie mir über die Kontaktseite.