Archiv

Scrumban

Agile Methoden sind heute sehr verbreitet, denn ihre Vorteile, wie Transparenz, und Flexibilität, sind unbestritten.Mehr als 84% aller Unternehmen verwenden die Agile Praktiken mindestens teilweise. Natürlich, für ein oder anderes Unternehmen, das Team oder Tätigkeit können nicht die selbe Methode geeignet sein. Es fällt oft schwer zu entscheiden, welche zu wählen.

Schauen Sie sich folgende Infografik an und erfahren, welche Agile Methode für Sie am besten passt.

 

Waelen Sie Ihre Agile Methode aus

Post-it_420_bizior_SXCVor einige Zeit habe ich meine interessanteste Scrum und Kanban Boards vorgestellt. Diesmal möchte ich diese beide Lösungen mischen und die Möglichkeiten einer strengeren Kanban-Tafel und einer lockeren Scrum-Tafel überblicken.

Da die meisten Teams selten ihr Projektmanagement mit Scrumban starten, entwickeln sie in dieser Entscheidungsphase eigenes individuell strukturiertes Board und lassen sich auch spezifische Prozesse einrichten. Schauen Sie an, welche Scrumban Boards mir aufgefallen sind:

 

Taskboard

Wayne Grant und sein Team ist ein gutes Beispiel, wie man das Board visuell gestalten kann. Es ist allen Teammitglieder sichtbar und immer Up-to Date. So wird der Informationsaustausch aller Mitarbeiter besser organisiert und der Beitrag jedes einzelnen Mitglieds effizienter gestaltet.

all-boards.jpg

Quelle: waynedgrant

 

Hourglass Scrumban Board

 Wenn Sie schnell die Engpässe in Ihrem Team identifizieren möchten, schauen Sie mal auf das Hourglass Scrumban Board. Kreative Umsetzung von WIP Limits, klare und übersichtliche Darstellung der Arbeit und keine Unordnung auf der Wand.

hourglass_scrum_kanban_board

 

Stanford Dev Team Board

Das Board von Stanford Universität für Tracking von Teamarbeit der Developer. Eine schöne Mischung aus Scrum und Kanban – visuell und einfach gestaltet, aber die Prioritäten bleiben erhalten.

scrumban-board-for-tracking-dev-team-work

Quelle: glassdoor

 

RapidMiner’s Scrumban board

Scrumban für Agile Marketing? Ja, richtig. Für einen Startup wie RapidMiner ist die Flexibilität sehr hohe Anforderung. Begonnen mit Kanban, haben die Teammitglieder schnell bemerkt, dass Kanban alleine für sie nicht ganz passt, deswegen war Scrumban für sie die beste Lösung.

1-UsswUVBvBwMVVoXTdfgQxg

Quelle: tomwentworth

 

Der erste Sprint

Das letzte, beim ersten Sprint erstellte Board, präsentiert Carlos Iglesias Pichel. Nach einiger Suche hat er zusammen mit seinem Team beschlossen, mit Scrumban zu starten. Flexibel, leicht anpassend und universell – Scrumban hat ihnen die beste Produktumgebung geboten. Auf dem Foto sehen Sie, was sie an diesem ersten Tag erreicht haben.

idea-1296646_960_720.jpgFür die Teams, die Agile erfolgreich eingeführt haben, kommt die logische Frage auf: was kommt als nächstes? Obwohl es manchmal nicht mehr nötig ist, den nächsten Schritt zu machen, weil die Methodik perfekt passt, bringen solche Modifikationen bessere Ergebnisse und höheren Wert.  Also, was Sie tun sollten, wenn Sie auch weitere Innovationen möchten? Hier sind einige Tipps:

 

Agile Skalierung mit LeSS

Eine der populärsten Agile Modifikationen – Agile Skalierung mit LeSS. Grundgedanke dieses Frameworks liegt daran, dass statt viele Teams zu koordinieren – also mehrere Scrum Master, Product Owner – wird das Entwicklungsteam einfach erweitert. So haben wir nur einen Product Owner für alle Teams, die an einem Produkt arbeiten. Da LeSS eine Weiterentwicklung von Scrum ist, verwendet dessen Konzepte und Begriffe. Der Hauptunterschied zu Scrum liegt daran, dass es die neuen Meeting-Typen definiert werden und die Organisation der bekannten Meetings zum Teil ändert. Schauen Sie mal an, ob LeSS in Ihrem Fall passt:

 

less-small.png

Quelle: less.works.de

 

Arrow Kanban

Für die Teams, die Kanban praktizieren, ist der Prozess so einfach, dass sie üblicherweise nicht notwendig finden, ihn zu ändern. Aber eine Sache, die oft in den Kanban-Teams geändert wird, ist das Taskboard. Es werden verschiedene Boards übernommen, um mehr Klarheit zu bringen und den Prozess besser darzustellen. Eine der populärsten Möglichkeiten, das Board zu innovieren, ist die Adoption der Pfeil-Form, die ermöglicht, Projekte schnell und einfach zu navigieren.

 

thearrow-overview_3

Quelle: theagileist

 

Volcano Kanban

Eine andere Möglichkeit, das Kanban Board zu wechseln, ist Verwandlung zu einem Vulkan. Diese Art der Arbeitsorganisation ist besonders für solche Unternehmen geeignet, in denen mehrere Teams an den Multiprojekten arbeiten und den Fortschritt auf dem Board korrelieren und überwachen müssen. Im Gegensatz zu dem traditionellen Kanban Board, wird das Board in bestimmte Abschnitte aufgeteilt – für Produkte und für jedes Team. Diese Aufteilung ermöglicht die Planung und Priorisierung der Arbeit auf globaler Ebene, während die Prozesse der einzelnen Team getrennt sind.

 

thevolcano-example_v2-0.png

Quelle: theagileist

 

Scrumban

Für diejenige, die mit Scrum, Kanban oder beide gearbeitet haben, und immer noch das Gefühl haben, dass die Methoden allein nicht so stark sind, ist Scrumban eine perfekte Möglichkeit. Im Vergleich zu Scrum, ist Scrumban eine flexiblere Lösung, die ermöglicht, mehr Freiheit bei der Planung und Ausführung der Aufgaben zu haben. Im Vergleich zu Kanban, setzt Scrumban die Prioritäten für Projekte, die dies erfordern. So wird Ihr Team das Beste aus beiden Methoden erhalten.

 

Scrumban

Quelle: Eylean

 

PRINCE2 Agile

Und zum Schluss – eine ungewöhnliche Mischung PRINCE2 Agile. Obwohl auf dem ersten Blick diese zwei zu unterschiedlich sind, nebeneinander zu stehen, scheint dieser Mix starke Vorteile zu haben. Es vereint die Grundlagen beider Methoden: Agile Rollen, Artefakte, Ereignisse und Praktiken in Kombination mit den klaren Strukturen von PRINCE2. PRINCE2 Agile™ unterstützt Unternehmen dabei, den starren Abläufen entgegenzuwirken und die Mitarbeiter zu mehr Selbstständigkeit bei ihren täglichen Arbeitsabläufen zu befähigen.

prince2.png

Quelle: attrapartners

 

 

Verwenden Sie eine von den erwähnten oder eine andere Agile Modifikation? Teilen Sie Ihre Erfahrung mit!


Ein vor kurzem veröffentlichter Bericht von  State of Agile hat nicht nur hervorragende Statistiken bekannt gegeben, aber auch einige Fragen gestellt, in welche Richtung Agile weiterentwickeln wird. Wie wird es in ein paar Jahren aussehen, welche Interessentengruppen werden sich bilden und wieviel von dem, was wir heute als Agile nennen, tatsächlich ändern wird?

Um einen besseren Blick auf diese und andere Fragen zu bekommen, haben wir tiefer die Statistiken nachgeschaut und stellen vor, wie, unserer Meinung nach, die Antworten aussehen sollten. Schauen Sie sich die Infografik an und erfahren unsere Prognosen für die Zukunft von Agile.

Agile-2016-DE

Wie meinen Sie, was erwartet Agile in Zukunft? Teilen Sie uns Ihre Gedanken mit!

crossfit-534615_960_720

Es besteht kein Zweifel, dass Agile Methode nicht mehr nur für Entwickler bekannt sind. Obwohl Agile Methoden aus der IT kommen, haben sie ihren angestammten Bereich längst verlassen und schon einige Zeit werden sie nicht nur in kleineren Teams und in den spezifischen Branchen übernommen. Aber einige wissen immer noch nicht, wie weit die Agile Methode wirklich verbreitet sind.

Wer hätte gedacht, dass diese Methodik im Sport eingesetzt wird? Ja, Sie haben richtig gelesen, Agile Methode werden nun für die Planung und Organisation im Sport verwendet.

Zum ersten Mal haben wir über diese Neuigkeit von einem serbischen Trainer Mladen Jovanović gehört. Sein ganzes Leben hat er aktiv an verschiedenen Aktivitäten beteiligt und vor kurzem hat über Agile Methodik und Eylean Board gehört.

Als Innovator begann er sich interessieren, wie die neue Erfahrung in seine Arbeit zu übernehmen und welches Nutzen es bringen könnte.  Wie hat er das geschafft? Schauen Sie sich mal ein kurzes Video an.

table-451357_960_720.jpgHeutzutage immer mehr Unternehmen suchen nach neue Möglichkeiten für Ihr Projektmanagement. Agile Methode sind im Moment “Number one”, besonders Scrum. Obwohl die Meisten Scrum in verschiedenen Bereichen erfolgreich eingesetzt haben, haben einige das Gefühl, dass diese Methode zu streng ist und das Endergebnis gleich bleibt – das Team, das 100% nicht erreicht. Für manche solche Unternehmen erscheint dann am Horizont eine Lösung – Scrumban.

Scrumban ist eine Mischung aus Scrum und Kanban. Diese Methode bringt einige Komponente beider Praktiken zusammen, um eine neue, verbesserte und mehr universelle Methode zu erstellen. In meinem Beitrag konzentriere ich mich nicht auf die gesamte Methodik, sondern werfe einen Blick darauf, wie Scrumban den Prozess eines erfolglosen Teams verbessern könnte. Es gibt verschiedene Gründe, warum die Teams Scrum-Methodik als unpassend finden: strikte Formalismen, Rollen und Artefakten, Zeitdruck, kontinuierliche Planung u.a. Für solche Teams ist Scrumban eine tolle Lösung, weil die Methode immer noch die wichtigste Scrum Prinzipien erhält, aber zugleich bietet mehr Flexibilität und Freiheit vorwärts zu bewegen.

Mit Scrumban kommen auf dem Board die erste Veränderungen und   Visualisierung des Prozessablaufs. Das bisherige Scrum Board erweitert sich, um die zusätzlichen Spalten für den Fortschritt unterzubringen, repräsentiert jeden Schritt der User Story vom Erstellen einer Aufgabe, bis sie komplett fertig ist. So kann man die Bewegung von Aufgaben genauer zu verfolgen und sofort die Probleme zu identifizieren.

Scrumban

Nächste große Änderung im Prozess sind Planung und Review-Meetings. Die üblichen Meetings werden nur dann geplant und organisiert, wenn sie nötig sind. Auf solcher Weise verschwenden wir die Zeit für die unnötigen Vorbereitungen nicht mehr. Ohne Planungssitzungen sind keine Sprints mehr möglich und das Team beginnt mit dem Kanban Pull-Prinzip. Die Aufgaben werden dann anhand ihrer Priorität vom Projekt-Backlog genommen und  in die aktive Warteschlange geschoben. Dadurch bekommt das Team besseres Verständnis über den Arbeitsumfang, was noch zu tun ist, und selbstständiger die neue Aufgaben erstellt und erledigt.

WIP limitsDa die Sprints nicht mehr organisiert werden, werden die Tasks im Progress anders begrenzt. Kanban WIP (Work in Progress) Grenzen sind auch in Scrumban eingeführt, um die Anzahl der Aufgaben, die gleichzeitig bearbeitet werden, zu begrenzen. Deshalb, wenn, z.B. die maximale Anzahl von Aufgaben im Progress drei ist, können die Teammitglieder gleichzeitig mehr Tasks nicht bearbeiten. Dadurch können die Teams rechtzeitig zusätzliche Hilfe schaffen, bevor eine Situation problematisch wird.

Eines, was bei Scrumban mehr oder weniger gleich bleibt, sind tägliche Sitzungen. Sie sind, aber, auf die einzelne User Stories, unerwartete Probleme und Fehlern konzentriert. Das Hauptziel der täglichen Sitzungen ist die User Stories zu identifizieren, die Schwierigkeiten haben und die Lösung finden oder die zusätzliche Ressourcen bereitzustellen, damit der Fortschritt des gesamten Projekts nach vorne geht.

ZykluszeitZum Schluss, können die User Stories noch in den Story Points geschätzt werden, aber bei Scrumban haben wir noch eine wertvolle Metrik – Zykluszeit. In dieser Metrik sehen wir, wieviel Zeit es dauert, bis eine Aufgabe abgeschlossen ist, es werden auch die Projektlaufzeit und die erforderlichen Ressourcen besser geschätzt. Zykluszeit kann auch helfen, problematische User Stories zu identifizieren, indem den Pfad der durchschnittlichen Bearbeitungszeit zeigt und sucht nach Abweichungen, die hinweisen, dass die Teammitglieder  auf Schwierigkeiten gestoßen sind.

Scrumban ist kein fest stehender Begriff, umgekehrt – ausgesetzt der individuellen Interpretation und, obwohl diese Methode als Missachtung von einigen Scrum Praktiken ganz negativ zu beurteilen ist, bringt ins Team mehr Verantwortung und Selbstständigkeit. Die zusätzliche Tools und Metriken stellen sicher, dass das Ziel ordnungsgemäß erreicht wird. Scrumban ist eine gute Option für die Teams, die sich ständig unter Druck fühlen, die User Stories rechtzeitig abzuschliessen. Scrumban sollte, aber, Schritt für Schritt umgesetz werden und nur dann, wenn das tatsächtlich die beste Lösung ist, sonst kann ebenso schädlich wie die Methodik zuvor sein.

Wir, Eylean Team, versuchen immer flexibel zu sein und an Bedürfnisse unseren Kunden zu orientieren. Schon einige Zeit hatten wir Gefühl, dass die Deutsche Sprache immer mehr benötigt wird. Deswegen haben wir schließlich beschlossen, Eylean Board ins Deutsche zu übersetzen.

Überzeugen Sie sich selbst und vergessen nicht, uns Ihr Feedback zu geben! Vielleicht gibt es andere Sprachen, die Sie in Eylean gerne sehen würden?

 

Board

Task

Statistik.png

 

teamwork-383939_640Vor kurzem haben wir über Iterationen, Arbeitsabläaufe und Scope Limits geschrieben, jedoch steht in Scrum, Kanban und Scrumban das Team in Zentrum. Deswegen werden wir in diesem Beitrag diesmal die Unterschiede zwischen diesen drei Methoden von der Seite der Teammitglieder, Sitzungen und kontinuierlicher Verbesserung überprüfen.

Teammitglieder

Im Allgemeinen ist Scrum eine Methodik, wo die Teammitglieder funktionsübergreifend sein können. Obwohl es keine genaue Definition gibt, was funktionsübergreifend bedeutet, das Team sollte die Fähigkeit besitzen, die Arbeit innerhalb jeder Iteration abzuschließen. Da Scrum eine zeitlich begrenzte Methodik ist, kommt es oft vor, dass einige Teammitglieder mit verschiedene Tasks-Typen arbeiten müssen, um die Arbeit während des Sprints abzuschließen. Aber, wie oben erwähnt, definiert die Methodik nicht explizit, was funktionsübergreifend bedeutet.

Bei Kanban ist, dagegen, die Spezialisierung der Teammitglieder oder Priorisierung der Tasks bevorzugt. Da die Arbeit durch “work in Progress” begrenzt ist, kann jeder mit anderem Element aus dem Backlog  starten, sobald man fertig mit eigenen Aufgaben ist. Das ermöglicht die Spezialisierung der Teammitglieder.

Bei Scrumban kann das Team entweder spezialisiert, oder funktionsübergreifend sein.

Sitzungen

Scrum kennt einige Arten von Sitzungen, die immer einem bestimmten Zweck dienen und zu definierten Zeitpunkten im Scrum Prozess stattfinden. Das sind Sprint-Planung, Daily Scrum und Retrospektive.

Sprint-Planungssitzung erfolgt vor jedem Sprint. Das Team entscheidet, welche Tasks aus dem Produkt-Backlog im kommenden Sprint bearbeitet werden, priorisiert die User-Stories.

Wie der Name andeutet, findet Daily Scrum oder Stand-Up-Sitzung täglich statt, wo jeder Teammitglied kurz berichtet, was er gerade arbeitet. Daily Scrum dauert nicht länger als 15 Minuten.

Retrospektive präsentiert den Teamprogress nach jedem Sprint. Die Teammitglieder besprechen die Möglichkeiten,  wie der Prozess zu verbessern und zu optimieren.

In Kanban und Scrumban sind die Sitzungen optional. Sie können völlig vermieden werden oder bei Bedarf vereinbart.

Kurze Kaizen-Events können Zeit zu Zeit durchgeführt werden, um sich besser zu fokussieren. In dieser Sitzung werden die Probleme untersucht, mögliche Lösungen vorgeschlagen und die Änderungen implementiert.

 

Kontinuierliche Verbesserung

Agile Vorgehen betonen, wie wichtig die Zusammenarbeit der Projektmitglieder ist. Der kontinuierliche Verbesserungsprozess charakterisiert die stetige Verbesserung der Produkt-, Prozess- und Servicequalität.

Scrum erreicht kontinuierliche Verbesserung durch die Sprint-Retrospektive Sitzung nach dem Sprint, wo die noch offene Frage und Probleme geäußert und bewältigt werden.

Bei Kanban und Scrumban ist kontinuierliche Verbesserung optional. Aber, wie oben erwähnt, kurze Kaizen-Events können für diesen Zweck auch verwendet werden.

Fazit

Agile Ansätze haben ein Ziel: frühere und öfter bessere Ergebnisse. Wir hoffen, dass dieser kurzer Artikel hat Ihnen geholfen, den Nutzen Agiler Methoden zu sehen und, dass nur durch die gemeinsame Arbeit man das richtige Ziel erreichen kann.

1574931134_d04e0a2dbdWährend die Agile Methoden immer mehr populär werden, ergeben sich manchmal die Fragen, was genau sie bedeuten und wie sie sich voneinander unterscheiden. Deswegen gehen wir weiter mit der Artikelserie über Scrum, Kanban und Scrumban, und in diesem Blog-Beitrag vergleichen diese drei Methoden, um zu zeigen, wie sie sich in verschiedene Abmessungen unterscheiden.

ITERATIONEN

Iterationen sind die begrenzten Zeitrahmen, in den ein Teil der Arbeit oder eine Aufgabe (Task) fertig ist. In Scrum arbeiten die Teams in der Regel in 1-4 Wochen Sprints, während der die Aufgaben vor der Frist fertig sind. Die Länge eines Sprints sollte möglichst stabil bleiben, damit der konsequente Überprüfungsmechanismus geschaffen wird.

Kanban hingegen verfügt keine vordefinierten Iterationen, sie sind viel flexibler. Stattdessen, arbeiten die Teams kontinuierlich, verwenden die Releases, die kürzer als eine Woche sind oder größere Iterationen wie Goals.

Scrumban kombiniert die beiden Methoden. Kontinuierliche Arbeit wird zusammen mit kurzen Iterationen für die Planung verwendet, und längere Zyklen – für das Release.

ARBEITSABLÄUFE

Arbeitsabläufe definieren, wie die Aufgaben unter den Teammitglieder verteilt sind. Das Push-Prinzip bezeichnet, dass die Aufgaben an die Teammitglieder in einer zentralisierten Weise zugeordnet werden. Das Pull-Prinzip bedeutet, dass die Aufgaben „gezogen“ oder von den Teammitgliedern selbst gewählt werden.

Scrum, Kanban und Scrumban sind die agilen Methoden, die Pull-Prinzip verwenden – wobei die Teammitglieder die Aufgaben wählen, die sie bearbeiten möchten.

In Scrum werden die Aufgaben früh von den Teammitgliedern gewählt. Vor jedem Sprint werden die Aufgaben von den Teammitgliedern gewählt oder sie werden an den Tasks gebunden.

Kanban und Scrumban verwenden beide die späte Bindung – wobei die Aufgaben während des Arbeitsprozesses gewählt werden. Sobald die aktuelle Aufgabe abgeschlossen ist, können die Teammitglieder frei weitere Aufgaben, die sie bearbeiten möchten, wählen. Das wird die späte Bindung der Tasks an den Teammitglieder genannt.

SCOPE LIMITS

Scope Limits definieren, wie der Arbeitsaufwand in den agilen Methoden beschränkt wird.

In Scrum wird der Arbeitsaufwand mit jedem Sprint begrenzt. Die Aufgaben (Tasks) können den Arbeitsumfang, der in einem Sprint getan werden kann, nicht überschreiten. Wenn eine Aufgabe innerhalb eines Sprints nicht abgeschlossen werden kann, wird sie in der Regel in kleinere Aufgaben aufgeteilt, die dann in einem Sprint passen könnten. Z.B., wenn wir einen großen Projekt haben, wird er in so viel kleineren Aufgaben aufgeteilt, dass jede in einem Sprint abgeschlossen wird.

In Kanban und Scrumban definieren die Work-in-Progress-Limits den Umfang der Arbeit. Deshalb, wenn die maximale Anzahl von Aufgaben im Progress drei ist, können die Teammitglieder gleichzeitig mehr Tasks nicht bearbeiten. Der Hinweis auf die Probleme im Progress in Echtzeit ermöglicht es Teams, die zusätzliche Hilfe zu schaffen, bevor eine Situation problematisch wird.

Man kann auch Scrum, Kanban und Scrumban kombinieren, damit die Arbeit des Teams die beste Qualität erreicht. Aber was für ein Team oder einen Projekt passt, muss nicht unbedingt für andere auch passen. Deswegen ist es wichtig die Projektmanagement Tools zu recherchieren. Unsere Lösung – Eylean Board, wo man die beliebige Tafel erstellen kann (siehe Bild). Über die Scrum und Kanban Projekte auf “Eylean Board” haben wir in früheren Beiträge erzählt.

Capture2

Im früheren Beitrag wurden die Hauptunterschiede zwischen Scrum, Kanban und Scrumban erläutert. In diesem Blogpost werfen wir einen tieferen Blick und schauen, wie die Tasks in jeder Methodologie geplant  werden, und auch wie die Performance in Scrum, Kanban und Scrumban gemessen wird.

 kanban_board

Planung

Planungsroutinen definieren, wie die Arbeit während des Prozesses geplant wird und wann die Planungsrunden stattfinden.

In Scrum werden die Produkt-Backlog-Items in jeden Sprint gezogen. Die Planung ist regelmäßig und erfolgt am Anfang jedes Sprints.

In Kanban, andererseits, werden die präzisen Planungen vermieden. Deswegen können die Teams wählen, wann sie die Elemente  aus dem Backlog ziehen (Bedarfsplanung) oder wann der Code oder die Version freigegeben wird (Release/Iterationsplanung). In Scrumban, ähnlich wie in Kanban, wird die Planung durchgeführt, wenn die Backlog-Items abgeschlossen sind und dann werden die neuen Items geplant.

Schätzung

Schätzung ist ein Prozess, indem die Zeit zum Abschließen jedes Items bestimmt wird.

In Scrum wird die Schätzung, in der Regel, vor Beginn des Sprints durchgeführt. Im Allgemeinen  müssen die Items kürzer als die Zeit für Time-Box Iterationen sein. Wenn nicht, dann werden sie normalerweise in kleinere Items unterteilt.

In Kanban und Scrumban ist die Schätzung der Laufzeit eines Items optional. Nachdem ein Item abgeschlossen ist, ziehen die Teammitglieder einfach das nächste Item aus dem Backlog und beginnen ihn zu bearbeiten. Einige Teams wählen dennoch die Schätzung für mehr Erwartungssicherheit. Es ist auch andere Möglichkeit die Erwartungssicherheit zu erreichen: sicherzustellen, dass jeder von diesen Items derselben Größe ist, deshalb können in der gleichen Zeit abgeschlossen werden.

Neue Items in Iteration

Agile Methodologien definieren auch, wie die neuen Items zu Iteration addiert werden.

In Scrum ist es verboten, neue Items während des Sprints hinzufügen. Das neue Item muss auf die reguläre Planungssitzung warten, bis es in den Workflow aufgenommen wird. Wenn ein Projekt viele eingehende Items (z. B., Support) erhält, wird es allgemein empfohlen, Kanban zu verwenden oder auf diese Anforderung in Scrum zu verzichten.

In Kanban und Scrumban ist es möglich die neuen Items hinzufügen, wenn es genug Kapazität in der Queue gibt. Deswegen sind Kanban und Scrumban sehr hilfreich für Funktionen mit kontinuierlichem Fluss der neuen Items.

Performance-Metriken

Die Key-Performance-Metrik ist  in Scrum das Burn-Down-Chart. Das Burn-Down-Chart zeigt, wie viel Arbeit für jede Iteration jeden Tag oder jede Stunde des Sprints bleibt. Beispiel des Burndown-Charts wird unten gegeben.

burndown

Die blaue Linie zeigt ein typisches Burndown auf Stundenbasis, im Vergleich zum idealen Burndown (die Punktlinie). Die grüne Linie repräsentiert den kumulativen Wert. Das Hauptziel des Burndown Diagramm ist zu zeigen, wo sich das Team in jedem Sprint befindet – hinter oder vor dem Zeitplan.

In Kanban wird die Performance durch die kumulative Flussdiagramme und Schätzung von Bearbeitungszeit gemessen. Kumulatives Flussdiagramm zeigt die Gesamtanzahl der Items, die im Progress sind, sowie die Zeit, in der sie abgeschlossen werden. Durchschnittliche Bearbeitungszeit zeigt, wie viel Zeit man ungefähr braucht, um ein Item abzuschließen. Ein Beispiel der Zykluszeitschätzung  wird unten gegeben. Ähnlich wie bei Kanban, wird bei Scrumban durchschnittliche Durchlaufzeit als Key Metrik verwendet.

lead_cycle_time

Es ist sehr wichtig zu beachten, dass Scrum, Kanban und Scrumban nur die Empfehlungen sind, und es gibt eine Vielzahl von Möglichkeiten, wie sie je nach Spezifikum des Teams eingesetzt werden könnten. Im nächsten Blog-Beitrag werden wir kurz die Iterationen, Arbeitsroutinen und Scope Limits vorstellen, damit es Ihnen deutlicher wäre, welche Methodologie für Ihr Team am besten ist.