Keine Artikel gefunden.

Was ist der Unterschied zwischen Sprints und Versionen in Jira?

Inhalt
Dies ist ein Text innerhalb eines div-Blocks.
Dies ist ein Text innerhalb eines div-Blocks.
Dies ist ein Text innerhalb eines div-Blocks.
Abonnieren Sie unseren Newsletter

Jeder, der in der agilen Umgebung arbeitet, würde zustimmen, dass es eine Million verschiedener Begriffe gibt, die Sie verstehen sollten. Als Marketer ohne Erfahrung in agiler oder Softwareentwicklung trifft das definitiv auf mich zu. Sobald Sie die Definition verstanden haben, müssen Sie verstehen, welche Rolle die einzelnen Komponenten im Entwicklungslebenszyklus spielen und wie sie sich in die zugehörige agile Methodik integrieren lassen 🤯

Um jegliche Verwirrung zu vermeiden, passt es nur, dass ein paar dieser Schlüsselbegriffe entschlüsselt werden... Sprints und Versionen. Welche Teams verwenden sie? Worauf beziehen sie sich eigentlich? Wie tragen sie zum Entwicklungszyklus bei?

Bevor Sie sich damit befassen, ist es wichtig, den Kontext zu berücksichtigen. Die Umgebung jedes Teams wird einzigartig sein und Sprints und Versionen können unterschiedlich integriert werden. Das Ziel dieses Blogbeitrags ist es, ein umfassendes Verständnis von beiden zu vermitteln. Sie können diese Informationen als Grundlage nehmen, auf der Sie aufbauen, an die Umgebung Ihres Teams anpassen und in einem nachhaltigen Tempo arbeiten können.

Versionen auf den Punkt gebracht

Im Wesentlichen ist eine Version der Höhepunkt der Arbeit Ihres Teams, die Sie an den Kunden versenden. Sie enthält häufig eine Reihe von Funktionen und Problembehebungen, die zusammen als ein einziges Update für Ihr Produkt veröffentlicht werden. Sowohl Scrum- als auch Kanban-Teams können in Versionen arbeiten.

Versionen und Releases werden oft synonym verwendet und orientieren sich an einem bestimmten Zeitpunkt oder einem Meilenstein, auf den Ihr Team hinarbeiten kann. In Jira hilft das Arbeiten mit Versionen dem Team bei der Organisation von Problemen. Wir können eine Version als einen Container von Problemen betrachten, die alle mit einer Kunden-Versionsnummer versehen wurden. Die Version oder Version ist das Ergebnis dessen, woran Ihr Team gearbeitet hat. In diesem Stadium ist die neueste Version bereit für den Versand.

Sprints auf den Punkt gebracht

Im Kern ist ein Sprint ein fester Zeitblock. Während dieser Zeit versuchen Entwicklungsteams, Verbesserungen oder eine neue Funktion für ein Produkt zu implementieren und bereitzustellen. Ganzheitlicher betrachtet könntest du einen Sprint als eine Art Rhythmus für die Arbeitsweise deines Teams betrachten. Scrum-Teams arbeiten in Sprints, Kanban-Teams dagegen nicht. Ein Sprint sieht feste Zeitrahmen vor, die in Scrum gut funktionieren. Kanban fordert das Team auf, einen kontinuierlicheren Arbeitsfluss einzuführen, weshalb Sprints normalerweise nicht eingehalten werden.

In Jira stammt die Arbeit, die du während eines Sprints erledigst, aus deinem Backlog. Sobald du deinen Sprint mit Problemen oder Geschichten zum Handeln gefüllt hast, kann dein Team jetzt mit der Arbeit beginnen. Am Ende des Sprints besteht die Idee darin, eine funktionierende Komponente des Produkts zu haben. Die Arbeit in Sprints gibt Ihrem Team die Möglichkeit, Ihr Arbeitspensum in kleinere, überschaubarere Arbeitsabschnitte zu unterteilen. Sie können sich dafür entscheiden, die Probleme, an denen Sie während eines Sprints gearbeitet haben, in die Version zu verschieben, die Sie an den Kunden versenden.

Kontrast

Oft hilft es, Sprints und Versionen zu trennen, indem man das Motiv berücksichtigt. Sprints konzentrieren sich auf die interne Arbeit, die erledigt werden muss, und eine Version als externe Ergebnisse, die der Kunde erhält. Der Hauptunterschied besteht darin, Sprints als Zeitfenster und Versionen als einen bestimmten Zeitpunkt zu betrachten.

Versionen sind stärker kundenorientiert, während Sprints spezifischer auf die Kapazität des Teams zugeschnitten sind. In Jira priorisiert ein Scrum-Team bei der Auswahl der Probleme aus deinem Backlog die Probleme in Sprints. Ein Kanban-Team nimmt immer das wichtigste Element und arbeitet auf die Version hin.

Einige Teams organisieren möglicherweise Sprints, um die Arbeit für eine bestimmte Version abzuschließen. Ein Scrum-Team könnte beispielsweise vier Sprints abschließen, bevor das Ergebnis die Version erreicht, wohingegen ein Kanban-Team eine weniger strukturierte Methode anwendet, um auf die neueste Version hinzuarbeiten.

Das Prinzip von Sprints und Versionen in Jira besteht größtenteils darin, deinem Team zu ermöglichen, deine Geschichten und Probleme so zu filtern, dass die Arbeit priorisiert wird, um die Umsetzung zu optimieren und die Effizienz zu verbessern. Einer der vielen Vorteile der Arbeit in einem agilen Team ist die Möglichkeit, zu erkennen, was funktioniert und wie es in Zukunft verbessert werden kann. Während Sprints oder Versionen für Sie jetzt funktionieren, ist dies möglicherweise nicht immer der Fall.

Machen Sie daraus, was Sie wollen, und überlegen Sie, wie das Framework aus Sprints und Versionen in Ihrer Umgebung am besten funktioniert, um Ihre eigene Teammethodik zu entwickeln. Ziehen Sie die User Story Maps for Jira von Easy Agile in Betracht, um den Fokus Ihrer Teams zu filtern und Ihr Backlog in Sprints oder Versionen zu priorisieren.

Schau in unserem Blog vorbei, um mehr zu erfahren!

Der ultimative Leitfaden für User Story Mapping

Easy Agile TeamRhythm
Verbessern Sie die Zusammenarbeit und Bereitstellung im Team

Verwandte Artikel

  • Workflow

    Warum User Story Mapping?

    Was ist User Story Mapping? Und noch wichtiger: WARUM sollten Sie eine Story-Mapping-Sitzung mit Ihrem Team durchführen wollen?

    Lassen Sie uns zunächst über die Ursprünge von User Story Mapping sprechen.

    Es ist heute eine gängige Praxis in der agilen Softwareentwicklung, aber das war nicht immer so.

    Wenn Sie Erfahrung mit einem Scrum- oder Kanban-Backlog haben, sind Sie wahrscheinlich auf den gefürchteten flachen Backlog gestoßen.

    Warum Story Mapping

    Flat backlog

    In seiner einfachsten Form ist ein flacher Produkt-Backlog eine lange Liste mit Dingen, die zu erledigen sind, die Ihren Benutzern/Kunden letztendlich einen gewissen Mehrwert bieten. Zumindest hoffen wir das.

    Viele von uns haben dazu beigetragen, dass diese Rückstände immer länger werden, und sie werden unweigerlich überwältigend.

    Unabhängig davon, ob das Team die Arbeit nacheinander aus dem Backlog herauszieht oder sie in Sprints gruppiert, bringt die Priorisierung der Arbeit in einem flachen Backlog ihre Herausforderungen mit sich.

    Das flache Backlog ist eine zweidimensionale Ansicht. Es ist wie eine Einkaufsliste, die keinen Kontext für die Arbeit bietet.

    shopping list

    Treten Sie ein, die User Story Map! Das Konzept einer User Story Map entstand aus dem Wunsch heraus, den flachen Backlog abzubauen und einen ganzheitlicheren, kundenorientierteren Überblick über unsere Arbeit zu schaffen.

    Eine User Story Map ist eine Visualisierung der Reise, die ein Kunde mit einem Produkt unternimmt, und beinhaltet die Aktivitäten und Aufgaben, die er normalerweise erledigen würde.

    story map


    Normalerweise wird zu Beginn eines Projekts eine User Story Mapping Session durchgeführt, die ausschließlich dem Ziel dient, ein gemeinsames Verständnis des Teams darüber zu schaffen, wer Ihre Kunden sind und wie Sie Ihre Zeit darauf konzentrieren sollten, an Geschichten zu arbeiten, die für sie den größten Mehrwert bieten.

    Sie können dies auf einem Whiteboard mit Haftnotizen tun, oder Sie können es in Jira mit unserer App tun. Einfacher agiler Teamrhythmus.

    So erstellen Sie eine User Story Map

    Um eine Visualisierung der Reise zu erstellen, die ein Kunde mit einem Produkt unternimmt, identifizieren Sie zunächst jede Phase und listen Sie dann die Aktivitäten und Aufgaben auf, die der Kunde normalerweise für jede Phase ausführen würde.

    journey

    Als Nächstes beginnen Sie, jedes Arbeitselement im Backlog dem entsprechenden Touchpoint in der Customer Journey zuzuordnen.

    An diesem Punkt in einer User Story Mapping-Sitzung sollte eine Matrix entstehen, die eine Liste von Aufgaben oder Geschichten enthält, zu deren Erfüllung sich das Team verpflichtet hat. Sie ist nach den Schritten der Customer Journey geordnet.

    steps

    Von dort aus ist die Karte in die Zeitblöcke unterteilt, die das Team zur Planung seiner Arbeit verwendet. Zum Beispiel könnte sich das Team in Sprint 1 auf 5 User Stories festlegen, die an 3 Epen angehängt sind.

    Dies hilft dabei, ein Verständnis dafür zu entwickeln, wie Fortschritte bei größeren Arbeiten erzielt werden können.

    Warum User Story Mapping besser ist als ein flaches Backlog

    Wenn die Arbeit im Backlog auf diese Weise mit der Kundenreise verknüpft wird, werden wichtige Fragen beantwortet wie:

    • WARUM bauen wir das?
    • Für WEN bauen wir das?
    • WELCHEN Wert wird es ihnen bieten?
    • WANN erwarten wir, dass wir das liefern werden?


    Beim User Story Mapping wird der zweidimensionale Backlog quasi in eine dreidimensionale Ansicht umgewandelt, da wir so sagen können: „Okay, ich arbeite gerade daran, diese User Story zu erstellen, und ich kann mir vorstellen, welchen Teil der Customer Journey sich das direkt auswirken wird UND wir wissen, wann sie bereitgestellt wird.“

    sprint swimlanes

    Indem eine Storymap den Nutzer in den Mittelpunkt stellt, stellt sie außerdem sicher, dass das Backlog Arbeiten enthält, die dem Kunden einen echten Mehrwert bieten, indem sie ihm helfen, seine Ziele zu erreichen.

    So führen Sie eine User Story Mapping-Sitzung durch

    Nachdem Sie nun den Wert einer User Story Map besser verstanden haben, schauen wir uns an, wie Sie eine User Story Map erstellen. Zunächst müssen Sie eine Story-Mapping-Sitzung mit Ihrem Team einrichten.

    Aber was auch immer Sie tun, machen Sie keine offene Einladung daraus. Das ist wirklich wichtig, denn wenn Sie nicht die richtigen Leute im Raum haben, wird es nicht effektiv sein.

    Personen, die Sie einladen könnten, sind:

    invite list

    Der Product Owner für das Team

    • ein technischer Leiter
    • ein User Experience Designer
    • ein Marketingleiter
    • ein Datenanalyst und
    • jemand vom Kundensupport

    Es ist auch wichtig, einige Grundregeln für die Sitzung festzulegen.

    Es sollte eine Person geben, die die Sitzung moderiert. Es empfiehlt sich, einen Produktmanager aus einem anderen Team mit der Durchführung der Sitzung zu beauftragen.

    Je nach Umfang der Story-Mapping-Sitzung möchten Sie vielleicht einen ganzen Tag Zeit nehmen oder die Sitzung auf mehrere Tage verteilen.

    Der Umfang hängt davon ab, wie groß Ihr Team ist und wie viele User Stories Sie Ihrer Map hinzufügen müssen.

    Außer dem Moderator sollten keine Telefone oder Laptops draußen sein.

    Außerdem sollte jeder im Raum mit den besprochenen User Stories vertraut sein.

    Nachdem Sie nun die Vorteile einer User Story Map kennen und wissen, was Sie bei der Einrichtung der Mapping-Sitzung mit Ihrem Team beachten sollten, sollten Sie darüber nachdenken, wen Sie zur Teilnahme einladen und die Sitzung moderieren können.

  • Workflow

    So holen Sie das Beste aus Ihren Sprintzielen heraus

    Das Sprintziel ist ein wichtiger Aspekt jedes Sprints und sollte während Ihres zweiwöchigen Prozesses im Mittelpunkt stehen. Das Ziel stellt sicher, dass sich das Team auf ein klares Ziel für den Sprint konzentriert, und wenn es gut gemacht wird, inspiriert das Team, während des gesamten Sprints auf Kurs zu bleiben.

    Was macht also ein gutes Sprintziel aus und wie passt das Sprintziel in den Rahmen eines Sprints? In diesem Beitrag werden wir im Wettlauf (oder sollten wir sagen Sprint 😉) eine Zusammenfassung des Scrum-Prozesses durchgehen, gefolgt von einer Liste mit fünf kritischen Elementen eines effektiven Sprintziels. Du erfährst, wie du deine Sprintziele für einen erfolgreichen Sprint alle zwei Wochen am besten erstellst, verwaltest und umsetzt.

    Ein Überblick über den Scrum-Prozess

    Wir sind große Fans von Gedränge! Brauchen Sie eine kleine Auffrischung? So funktioniert der Scrum-Prozess und wo das Sprintziel in das Gesamtbild passt.

    Scrum ist ein agiles Framework, das hauptsächlich von Softwareentwicklungsteams verwendet wird und den Teammitgliedern einen optimierten Arbeitsablauf bietet, um die Bedürfnisse von Stakeholdern und Kunden zu erfüllen. Der Scrum-Workflow umfasst vier Besprechungen (auch bekannt als Zeremonien), die alle einen bestimmten Zweck haben. Diese Struktur bedeutet, dass sich die Teammitglieder problemlos gegenseitig unterstützen können, indem sie Ergebnisse teilen, verfolgen und verbessern.

    Das Scrum-Framework unterteilt die Arbeit in sich wiederholende zweiwöchige Sprints, in denen ein festgelegter Arbeitsaufwand — das Sprintziel — abgeschlossen wird. Jedes Scrum beginnt mit einem Sprint-Planungsmeeting, und während dieser Zeit definiert der Product Owner das Sprintziel. Sie entscheiden, welche Aufgaben aus dem Produkt-Backlog in das Sprint-Backlog übertragen werden, um im darauffolgenden zweiwöchigen Sprint abgeschlossen zu werden.

    Die Artikel im Produktbacklog geben einen Überblick darüber, was vor der Fertigstellung oder Veröffentlichung eines Produkts zu tun ist. Die Elemente des Sprint-Backlogs sind das, was das Team (hoffentlich) im Laufe des Sprints erreichen wird.

    Das Scrum Master fungiert als Scrum-Guide, der das Team durch die Besprechungen und Schritte des Scrum-Prozesses führt. Während des gesamten Sprints trifft sich das Scrum-Team zu einem tägliches Scrum um miteinander abzuchecken und berichten Sie, welche Arbeiten in den letzten 24 Stunden abgeschlossen wurden.

    Am Ende des Sprints ein Sprint-Review und Sprint-Rückblick helfen Sie dem Team, Feedback von Stakeholdern einzuholen und ihre Prozesse zu verbessern, bevor der nächste Sprint beginnt. Der gesamte Prozess wiederholt sich bei der Sprint-Planung erneut und wiederholt sich so lange, bis das Produkt oder Projekt abgeschlossen ist.

    Einfache Sprint-Planung:

    Ziehe Elemente direkt aus deinem Backlog auf deine TeamRhythm User Story Map. Bearbeiten Sie Story-Zusammenfassungen und Story-Point-Schätzungen online. Zeige dein Sprintziel auf jeder Sprint-Swimlane an.

    PROBIERE: TEAMRHYTHM SANDBOX DEMO

    Was macht ein gutes Sprintziel aus?

    Das Sprintziel sorgt dafür, dass sich das Team darauf konzentriert, was jeder für jeden Sprint zu erreichen versucht. Es ist eine Erweiterung der allgemeinen Produkt- oder Projektziele, aber das Sprintziel kann sich auf wichtige Komponenten konzentrieren, die das Team für diesen bestimmten Sprint in Angriff nehmen möchte.

    Was macht ein gutes Sprintziel aus? Lass es uns herausfinden.

    1. Das Ziel ist erreichbar

    Das Ziel des Sprints muss innerhalb des für den Sprint vorgesehenen Zeitrahmens erreichbar sein. Im Allgemeinen ist das Team in einem Scrum-Framework an zwei Wochen gebunden.

    Wenn neue Informationen gewonnen werden und andere Hindernisse auftreten, besteht immer die Möglichkeit, dass das Sprintziel nicht erreicht wird. Das sollte Sie jedoch nicht davon abhalten, erreichbare Ziele zu setzen. Wenn ein Team die Ziele des Sprints und des Projekts kontinuierlich nicht erreicht, sinken die Moral und der Enthusiasmus.

    Es ist wichtig, dass die Sprintziele innerhalb der vorgegebenen Zeit des Sprints überschaubar sind. Sprintziele können zu groß werden, wenn ein Team versucht, zu viele verschiedene Komponenten gleichzeitig zu erledigen, oder wenn zu viel vom Produkt-Backlog in das Sprint-Backlog aufgenommen wird. Nehmen Sie stattdessen eine einigermaßen erreichbare Arbeitslast aus dem Produkt-Backlog heraus, um das Sprint-Backlog zu bilden. Andernfalls erhalten Sie am Ende eine entmutigende Gesamtliste und keine klare Richtung für jeden Sprint.

    2. Das Team versteht die Definition von erledigt

    Je klarer das Sprintziel, desto besser. Du musst die Ziele des Sprints klar definieren und klar definieren, was es bedeutet, getan zu werden. Woher weiß das Team, ob es die gewünschten Ergebnisse erzielt hat? Wie sieht „erledigt“ aus? Sind sich alle über diese Definition für jede gegebene Aufgabe und die Gesamtziele des Sprints einig?

    Deine Ziele müssen messbar sein, um Unklarheiten, Subjektivität oder widersprüchliche Meinungen über den Erfolg des Sprints zu vermeiden.

    Wenn ein Team aufeinander abgestimmt ist und jeder versteht, was erreicht werden muss, verbessert sich die Entscheidungsfindung und jeder Aspekt des Scrum-Teams kann harmonisch auf dieselben Ziele hinarbeiten.

    3. Das Sprintziel ist für das Team von Bedeutung

    Das Team muss nicht nur wissen, was das Team in jedem Sprint zu erreichen hofft, sondern auch die Gründe hinter dem Sprintziel verstehen.

    Stellen Sie sicher, dass jeder versteht, warum er auf ein bestimmtes Sprintziel hinarbeitet. Welche Bedeutung hat das Sprintziel? Im Idealfall bezieht sich die Bedeutung des Sprintziels auf die Bedürfnisse der Stakeholder, die Kundenreise oder die Benutzererfahrung Ihres Produkts.

    Visualisieren und priorisieren Sie die Arbeit, die Ihren Kunden den größten Mehrwert bietet

    Einfacher agiler Teamrhythmus

    VERSUCHE ES JETZT

    4. Das Sprintziel entspricht den allgemeinen Produktzielen

    Das Sprintziel kann sich auf einen bestimmten Aspekt der Produktentwicklung konzentrieren, sollte aber dennoch mit den allgemeinen Produktzielen in Verbindung stehen.

    Stellen Sie bei der Erstellung von Sprintzielen sicher, dass die übergreifende Produktvision nicht verloren geht oder ignoriert wird. Jeder Sprint ist zwar spezifisch für seine eigenen Ziele, sollte aber darauf abzielen, Ihre Produktziele zu erreichen.

    5. Das Sprintziel ist während des gesamten Sprints sichtbar

    Das Sprintziel kann kein „Setz es und vergiss es“ -Aspekt deines Sprints sein. Es sollte für das Team die ganze Zeit sichtbar sein, und das Team muss das Ziel kontinuierlich überprüfen, um sicherzustellen, dass es auf dem richtigen Weg ist, es zu erreichen.

    Das gemeinsame Ziel sollte im Mittelpunkt der täglichen Scrum-Meetings stehen. Wenn möglich, zeigen Sie das Sprintziel für alle sichtbar an. Beziehen Sie sich beim Erledigen der Backlog-Elemente und beim Durcharbeiten des Sprints kontinuierlich auf das Sprintziel und die Fortschritte, die Sie auf dem Weg dorthin machen. Wie wahrscheinlich ist es, dass Sie das Sprintziel erreichen, wenn Sie die verbleibende Zeit des Sprints berücksichtigen? Was könnte der Erreichung dieses Ziels im Weg stehen?

    Während der Sprint-Retrospektive solltest du den Erfolg oder Misserfolg besprechen, den das Team beim Sprintziel erzielt hat. Was lief gut und hat zu deinem Erfolg beigetragen? Was lief nicht so gut, dass du es für den nächsten Sprint ändern oder anders machen könntest?

    Mit Easy Agile TeamRhythm verfügt jedes Scrum Board in Jira über eine zugehörige User Story Map.

    Während des gesamten Sprints kann das Team auf die User Story Map zurückgreifen, um sicherzustellen, dass der Zeitplan eingehalten wird, Abhängigkeiten koordiniert und das Gesamtbild im Blick behält.

    MACHEN SIE EINE PRODUKTTOUR

    Ein kundenorientierter Ansatz

    Lassen Sie uns einige der wichtigsten Faktoren zusammenfassen, die Sie bei der Festlegung und Umsetzung Ihres Sprintziels berücksichtigen sollten:

    ✅ Stellen Sie sicher, dass das Ziel erreichbar ist.

    ✅ Stellen Sie sicher, dass das Team die Definition von erledigt versteht.

    ✅ Stellen Sie sicher, dass das Sprintziel für das Team von Bedeutung ist.

    ✅ Stellen Sie sicher, dass das Sprintziel mit den allgemeinen Produktzielen übereinstimmt.

    ✅ Stellen Sie sicher, dass das Sprintziel während des gesamten Sprints sichtbar ist.

    Vielen Dank, dass Sie bei uns bleiben und den Easy Agile-Blog nutzen. Wir sind begeistert davon, Teams dabei zu helfen, mit Agile besser zu arbeiten. Wir haben eine Suite von Jira-Apps entwickelt, um den Kunden bei jedem Schritt des Entwicklungsprozesses im Auge zu behalten.

    Suchen Sie nach einem Tool zur Optimierung Ihrer Sprint-Planungssitzungen? Auschecken Einfacher agiler Teamrhythmus, was den flachen Produktbestand in ein aussagekräftiges Bild der Arbeit verwandelt.

  • Workflow

    Was ist der Unterschied zwischen Kanban und Scrum?

    Kanban vs. Scrum — sind sie unterschiedlich und können Software- und Produktentwicklung sie zusammen verwenden? Die Antwort auf beide Fragen lautet JA!

    Sowohl Kanban als auch Scrum sind beliebte agile Methoden. Sie sind unterschiedlich, aber sie können zusammen verwendet werden. Sie sind alle Bestandteile von Agile, einer besseren Arbeitsweise, die sich auf Iteration und Zusammenarbeit konzentriert, um Verschwendung zu reduzieren und die Effizienz zu maximieren.

    Agile ist das Gegenteil von klassischem Projektmanagement. Stellen Sie sich das wie Jazz gegen klassische Musik vor. Anstatt dass ein Komponist ein bereits komponiertes und organisiertes Musikstück in ein Orchester bringt und diktiert, was wo passiert, ist Jazz kollaborativ, jedes Bandmitglied ernährt sich voneinander und kreiert Musik in einem agilen, iterativen Prozess.

    In diesem Beitrag werden sowohl die Kanban- als auch die Scrum-Methoden eingehend behandelt. Lesen Sie weiter, um die Unterschiede und Gemeinsamkeiten zwischen Kanban und Scrum zu entdecken und zu erfahren, wie sie zusammen effektiv eingesetzt werden können.

    Wie unterscheidet sich die agile Methodik vom Projektmanagement?

    Die traditionelle Projektmanagementmethode ist linear, was bedeutet, dass jedes Projektelement in sequentieller Reihenfolge abgeschlossen wird. Erst wenn jedes Element abgeschlossen ist, können Sie mit dem nächsten fortfahren. Stellen Sie sich das traditionelle Projektmanagement als eine Montagelinie vor. Es besteht aus einer strikten Abfolge von Schritten, die vom Projektmanager geplant werden, bevor neue Arbeiten oder Iterationen beginnen können.

    Der Projektmanager ist die Person, auf die das gesamte Team in Bezug auf die Führung angewiesen ist. Der Arbeitsablauf bleibt von Projekt zu Projekt derselbe, und die Schritte ändern sich selten.

    Im Gegensatz dazu ist Agile eine nichtlineare Arbeitsweise, die sich auf Flexibilität und Zusammenarbeit zwischen den Teammitgliedern konzentriert. Agiles Projektmanagement konzentriert sich darauf, etwas fertig zu stellen, das die Beteiligten regelmäßig sehen und bewerten können, sodass kontinuierlich ein Mehrwert geschaffen wird.

    Jede Iteration liefert sowohl vom Team als auch vom Kunden neue, umsetzbare Erkenntnisse darüber, was funktioniert, was nicht und was geändert werden muss. Es handelt sich um einen vielseitigen Ansatz, der die Engpässe beseitigt, die bei der herkömmlichen Methode auftreten können.

    Kanban gegen Scrum

    Kanban vs. Scrum ist keine Dichotomie. Beides sind agile Methoden, die Teams helfen sollen, in einem iterativen Prozess zu arbeiten. Bei beiden handelt es sich um Systeme, die regelmäßig im Entwicklungsprozess eingesetzt werden, um einen wertorientierten Ansatz zu gewährleisten. Die Ziele und Methoden sind dieselben, aber die Schritte sind unterschiedlich.

    Ein Kanban-Workflow ist eine Möglichkeit, Aufgaben visuell zu organisieren, um sicherzustellen, dass Arbeitselemente vorangetrieben werden, während gleichzeitig Änderungen und Anpassungen vorgenommen werden können. Ein Scrum funktioniert in Sprints von 2 bis 4 Wochen, die darauf ausgelegt sind, einen bestimmten Arbeitsaufwand zu erledigen oder ein bestimmtes Problem zu lösen. Während jedes Sprints checken die Teams täglich ein, um den Fortschritt sicherzustellen und mögliche Hindernisse zu identifizieren.

    Kanban vs. Scrum ist nicht die eine oder andere Wahl. Beide können gleichzeitig verwendet werden, je nachdem, was von Projekten verlangt wird oder Anwenderberichte. Im Folgenden erfahren Sie mehr über die Unterschiede und Gemeinsamkeiten dieser beiden Methoden.

    Kanban im Vergleich zu Scrum: Kanban-Methodik

    Kanban vs. Scrum: A Kanban board with colorful sticky notes

    Kanban wurde ursprünglich von Taiichi Ohno, einem Ingenieur bei Toyota, als schlankes Produktionssystem verwendet, das Verschwendung reduzierte und die Effizienz erhöhte. Die Kanban-Methode ist ein Tool zur Aufgabenverwaltung, das entwickelt wurde, um die Effizienz zu maximieren, indem alle erforderlichen Arbeiten visualisiert und die laufenden Arbeiten begrenzt werden.

    Arbeitselemente werden visuell auf Kanban-Boards dargestellt, sodass jedes Teammitglied den Status jeder Arbeit zu einem bestimmten Zeitpunkt sehen kann. Es ermöglicht Kommunikation in Echtzeit und volle Transparenz zwischen den Teammitgliedern, da jedes Arbeitselement bewusst zugewiesen wird. Ein Trello-Board ist ein einfaches Beispiel für ein Kanban.

    Wie benutzt man Kanban

    Mit einem Kanban durchläuft die Arbeit visuell verschiedene Fertigstellungsphasen, um eine kohärente Zusammenarbeit und Kommunikation in Echtzeit zwischen Teams zu fördern. In seiner einfachsten Form ist ein Kanban ein To-Do-, Do- und Done-Board. Die Arbeit wird auf einer physischen oder digitalen Kanban-Tafel von einem Abschnitt zum nächsten verschoben, je nachdem, wie weit die jeweilige Aufgabe fortgeschritten ist.

    Um komplexere Probleme zu lösen, was in der Softwareentwicklung normalerweise der Fall ist, kann ein Kanban weiterentwickelt werden, indem zusätzliche Ebenen für bestimmte Kunden, Produkte oder Ergebnisse hinzugefügt werden.

    Ein wichtiger Aspekt der Kanban-Methode ist, dass jede Person nur an einer Aufgabe gleichzeitig arbeiten darf. Dadurch wird sichergestellt, dass kein Aspekt jemals zu weit voranschreitet, ohne im Einklang mit den übrigen Aufgaben an Deck zu arbeiten. Das Einzelsystem identifiziert kritische Verbindungen zwischen Aufgaben sowie potenzielle Hindernisse, die zu Verzögerungen führen könnten.

    Wenn funktionsübergreifende Teams ermutigt werden, Arbeitsaufgaben bewusst zu identifizieren, wird sichergestellt, dass Aufgaben angemessen priorisiert werden. Es bekämpft auch die negativen Auswirkungen von Multitasking und ermöglicht es Entwicklern, sich jeweils auf eine Aufgabe zu konzentrieren.

    Kanban vs. Scrum: Scrum-Methodik

    Scrum, manchmal auch „Scrumban“ genannt, basiert auf Empirismus und Lean Thinking. Empirismus ist die Überzeugung, dass Wissen aus praktischer Erfahrung und objektiven, beobachtbaren Fakten stammt. Lean Thinking konzentriert sich auf das Wesentliche, schafft Mehrwert für den Einzelnen und vermeidet gleichzeitig Verschwendung. Ein Scrum setzt auf Zusammenarbeit in Echtzeit statt auf Theoretisierung, um einen schlanken Rahmen für die Lösung komplexer Probleme zu bieten.

    Der Scrum-Prozess verwendet einen interaktiven und inkrementellen Ansatz, der Risiken verwaltet und die Vorhersagbarkeit durch festgelegte Iterationsintervalle, sogenannte Sprints, verbessert. Die Sprints ergeben eine unvollständige, aber wertvolle Version eines Produkts, das das Team schnell den Stakeholdern vorlegen kann, deren Feedback dann in den nächsten Sprint integriert wird. Die Sprints werden so lange fortgesetzt, bis das gewünschte Ergebnis oder Produkt erreicht ist.

    Wie benutzt man Scrum

    Ein Scrum findet über einen bestimmten Zeitraum statt, der als Sprint bezeichnet wird. Jeder Sprint dauert in der Regel zwei Wochen bis maximal vier Wochen. Der wichtige Teil ist, dass der Zeitrahmen festgelegt wird, bevor das Scrum beginnt.

    Ein Scrum besteht aus drei Hauptkomponenten:

    1. Rollen: Die Leute

    • Inhaber des Produkts
    • Scrum Master
    • Entwicklungsteam

    2. Artefakte: Was wird gemacht

    • Produktrückstand
    • Sprint-Backlog
    • Zuwächse

    3. Zeremonien: Wiederkehrende Ereignisse

    • Sprint-Planung
    • Tägliches Scrum
    • Sprint-Bewertung
    • Sprint-Rückblick

    Der Product Owner ordnet und priorisiert Backlog-Artikel, also die Aspekte eines Produkts, die fertiggestellt werden müssen. Zu Beginn eines Scrums legt der Product Owner fest, welche Artefakte aus dem Produkt-Backlog in das Sprint-Backlog aufgenommen werden. Das Sprint-Backlog repräsentiert die Ziele und die gewünschten Ergebnisse des bevorstehenden Sprints.

    💡 Benutzen Einfacher agiler Teamrhythmus um flache Produktrückstände in wirkungsvolle, visuelle Repräsentationen umzuwandeln.

    Kanban vs. Scrum: An Easy Agile User Story Maps graphic

    Der Scrum Master hilft jedem, die Theorie und Praxis von Scrum zu verstehen. Sie sind für die Effektivität des Scrum-Teams verantwortlich. Während des 2-4-wöchigen Sprints konzentriert sich das Team auf den Backlog, Einchecken für die täglichen Scrums oder tägliche Stand-ups. Während dieser Scrum-Besprechungen teilen die Teammitglieder, was Storypoints sie abgeschlossen haben, welche Storypoints sie als Nächstes abschließen werden, sowie alle Straßensperren, die im Weg stehen.

    Die Ergebnisse werden regelmäßig produziert und bei Bedarf werden im Laufe der Zeit Anpassungen vorgenommen. A Scrum Board oder Kanban Board kann verwendet werden, um Teams dabei zu helfen, ihren Fortschritt während des Sprints zu visualisieren.

    Zeremonien sind die wiederkehrenden Ereignisse wird von Scrum-Teams abgehalten, die sich im Abstand von 2-4 Wochen durchqueren. Ein Scrum beginnt mit einer kurzen Planungsphase, danach beginnt die Arbeit. Das Scrum-Team trifft sich täglich, um die Fortschritte zu überprüfen und bei Bedarf Änderungen vorzunehmen.

    Am Ende jedes Sprints findet ein Sprint-Review mit Stakeholdern oder Kunden statt, um sicherzustellen, dass der Wert erreicht wird, und kontinuierliche Verbesserungen werden vorangetrieben. Schließlich findet ein retrospektives Meeting mit dem Projekteigentümer, dem Scrum Master und dem Entwicklungsteam statt, um die letzten zwei Wochen zu überprüfen, einschließlich der Erfolge, wichtigsten Kennzahlen und Herausforderungen, die vor Beginn des nächsten Sprints angegangen werden müssen.

    Kanban und Scrum zusammen verwenden

    Es muss nicht Kanban oder Scrum sein — sie können zusammenarbeiten. Ein Entwicklungsteam könnte sich dafür entscheiden, das Kanban-System in einem Scrum zu verwenden, um eine visuelle Darstellung der Arbeit zu bieten, die in jedem Sprint voranschreitet.

    Sie sind beide wertvolle Systeme in Ihrem agilen Toolkit, die zusammenarbeiten, um Priorisierung, Zusammenarbeit und konstante Wertschöpfung zu ermöglichen. Sie müssen sich also nie zwischen Kanban und Scrum entscheiden. Sparen Sie sich die Entscheidungsfindung für die eigentlichen Probleme auf, z. B. was Sie auf die Pizzen legen sollen, die Sie für Ihr Team bestellen. 🍕

    Ein Scrum-Framework bietet Teams bestimmte Zeitblöcke, um ein bestimmtes Ergebnis oder eine Reihe von Ergebnissen zu erledigen, und bietet gleichzeitig tägliche Scrum-Besprechungen an, um den Zusammenhalt und die Weiterentwicklung sicherzustellen. Das Kanban-System stellt sicher, dass Aufgaben in einem sich entwickelnden, visuellen Prozess nacheinander erledigt werden.

    Lernen Sie die Methoden von Scrum mit Easy Agile kennen

    Easy Agile entwickelt Lösungen, um jedes agile Team effektiver zu machen. Wir helfen Teams dabei, einfache und kollaborative Lösungen zu entwickeln User-Story-Maps in Jira für Backlog-Grooming, Versionsplanung und reibungslose Sprints.

    Wir glauben, dass es eine bessere Art zu arbeiten gibt, und wir möchten Teams wie Ihrem helfen. Erfahre mehr über unsere Suite von Agile Apps und folge unserem Blog für die neuesten agilen Trends, Tipps und mehr.