Eine Übersicht gängiger Metriken, Werkzeuge und Praktiken zur Bewertung und Abschätzung von Aufwänden in der agilen Produktentwicklung
Dieses Whitepaper stellt unterschiedliche Vorgehensweisen, Werkzeuge und Praktiken vor, um Dauer und Kosten von Entwicklungsvorhaben in komplexen Umfeldern abzuschätzen, und beleuchtet deren Vor- und Nachteile.
Prognosen helfen dabei, Entscheidungen zu treffen und Pläne zu modifizieren. Zugleich tun sich viele Unternehmen und Entwicklungsteam schwer damit, belastbare Schätzungen vorzunehmen und über Zeit anzupassen, wenn neue Erkenntnisse über Chancen und Risiken gewonnen werden.
Der erste Teil beleuchtet, warum Zeit bei komplexen Problemstellungen eine schwierige Schätzgröße ist, und welche Praktiken helfen können, unerwünschte Effekte abzumildern. Diese Werkzeuge werden für zeitbasierte Schätzungen vorgestellt: Ideale Tage und Drei- Punkt-Schätzungen.
Der zweite Teil widmet sich vergleichender Größenschätzungen, die in vielen agilen Setups eingesetzt werden. Hier werden diese Werkzeuge vorgestellt: Story Points, Velocity, Planning Poker, Affinity Estimation, Magic Estimation und Burndown Charts.
Der dritte Teil zeigt auf, wie empirische Daten genutzt werden können, um mittels stochastischer Verfahren die Eintrittswahrscheinlichkeit von Umsetzungs- und Lieferzeiten abgeleitet werden können. Die in diesem Abschnitt vorgestellten Werkzeuge sind: Lead Time, Cycle Time, Scatterplots und Monte Carlo Simulationen.
Erprobte Techniken für den Einsatz in der agilen Produktentwicklung mit Scrum
Der Scrum Guide definiert Scrum als leichtgewichtiges Rahmenwerk. Scrum ist bewusst unvollständig und schreibt nur sehr wenige Praktiken und Regeln vor. Damit folgt es dem Manifest für agile Softwareentwicklung, dessen Wertekanon Individuen und deren Interaktionen über festgeschriebene Prozesse und Werkzeuge stellt. Scrum Teams werden aktiv dazu ermuntert, immer wieder neue Werkzeuge und Praktiken auszuprobieren und in ihren Fundus an Scrum Werkzeugen zu integrieren. Durch die Auswahl und Evaluierung der für den jeweiligen Kontext geeigneten Tools, wird das Scrum Team in seiner Autonomie über den eigenen Arbeitsprozess gestärkt. Zugleich kann diese Freiheit Teams zunächst überfordern, die Scrum zum ersten Mal implementieren.
5 agile Werkzeuge, die Sie voran bringen
Die ersten Schritte in der agilen Produktentwicklung mit Scrum sind oft nicht leicht. Auf dieser Seite haben wir eine Auswahl an häufig verwendeten Werkzeugen und Praktiken zusammengestellt, die sich in vielen Kontexten als hilfreich erwiesen haben.
Personas
Ein Leitsatz agiler Produktentwicklung ist die Fokussierung auf die Kund:innen und ihre Bedürfnisse. Personas dienen dazu, diese im Entwicklungsprozess besser präsent und greifbarer zu machen. Dazu werden für die verschiedenen Zielgruppen, für die das Produkt einen Nutzen bieten möchte, archtypische Vertreter:innen erstellt. Personas verleihen der Kund:in einen Namen, Alter, Aussehen, Interessen und Hobbies, sowie eine Lebensgeschichte. Dadurch wird es einfacher, Anforderungen für diese Zielgruppe zu formulieren und Annahmen über mögliche Lösungen zu überprüfen.
3Cs für kreative Lösungsprozesse
Scrum würdigt die Expertise der Scrum-Team-Mitglieder. Das Scrum-Team sollte daher nicht als Umsetzungsfabrik für bereits vollends ausspezifizierte Lösungen misbraucht werden. Binden Sie möglichst viele Perspektiven bei der Kreation von Lösungsoptionen ein.
Ron Jeffries, Co-Author des Manifest für agile Softwareentwicklung, empfiehlt hier die 3C-Praktik. Die 3 Cs stehen für Card, Conversation und Confirmation. Diese Praktik können Sie sofort in Ihrem nächsten Refinement einsetzen:
Card: Schreiben Sie mit einem dicken Stift auf die Vorderseite eine Moderationskarte (A5), welches Problem Sie für eine bestimmte Persona lösen möchten. Bzw. welchen Nutzen Sie realisieren wollen. Halten Sie sich mit Details, die Sie sicher schon ausgearbeitet haben, bewusst zurück.
Conversation: Zeigen Sie die Karte Ihrem Team und relevanten Stakeholder:innen. Diskutieren Sie zusammen, welche Lösungsoptionen Ihnen dazu einfallen. Legen Sie sich nicht sofort auf die erste Option fest – fragen Sie das Team gezielt nach Alternativen. Beleuchten Sie gemeinsam Vor- und Nachteile der unterschiedlichen Vorschläge.
Confirmation: Einigen Sie sich auf eine Lösungsoption. Halten Sie auf der Rückseite der Karte die fachlichen Akzeptanzkriterien fest, die die Lösung bieten muss.
User Stories
Beschreiben die Einträge in Ihrem Product Backlog eher konkrete Umsetzungsideen und Lösungsstrategien als den erhofften Mehrwert für Nutzer:innen? Dann können User Stories dabei helfen Ihre Kund:innen besser in Ihrem Backlog zu repräsentieren. Eine User Story ist eine besondere Form, der Anforderungsdokumentation, die die Nutzer:in und den mit der Lösung verbundenen erhofften Mehrwert klar benennt. Dies gibt eine Orientierung während der Refinements und Umsetzung der Anforderung.
Hier erfahren Sie mehr über den Aufbau und Einsatz von User Stories.
User Story Maps
Eine User Story beschreibt eine einzelne Anforderung aus Sicht der Kund:in. Mit Hilfe von User Story Maps modellieren Sie das Erlebnis der Nutzer:innen für das Produkt oder relevante Teile des Produkts als Einheit. Dadurch wird es leichter, den roten Fadenüber die atomaren Bestandteile Ihres Produktes zu spannen und Usability und User Experience des Produkts zu steigern. Durch den Einsatz von User Story Mapping wird aus der Anforderungsliste Ihres Product Backlogs eine mehrdimensionale Karte. Dies hilft auch dabei, Minimal Viable Products (MVP) zu identifizieren und einzelne Anforderungen in Relation zu anderen zu priorisieren.
Hier erfahren Sie mehr über den Aufbau und Einsatz von User Story Maps.
Story Points & Velocity basierte Planung
Zeit ist eine schwierige Schätzgröße, da bei Schätzungen viele Variablen berücksichtigt werden müssen. Dazu zählt die Verfügbarkeit von Experten ebenso wie neue Chancen und Risiken, die sich während der Entwicklung ergeben. Viele agile Teams schätzen daher statt der Umsetzungsdauer den Umfang der Anforderungen. Als gängiste Schätzgröße gelten hier wohl Story Points. Die erwartete Entwicklungsdauer einer Anforderung wird dann über die bisherige Umsetzungsgeschwindigkeit (Velocity) abgeleitet.
Diese und weitere Verfahren für Prognosen in komplexen Umfeldern, stellen wir ausführlich in einem Whitepaper vor.
Coaching für Product Owner, Scrum Master und Führungskräfte
Sie haben Verantwortung als Product Owner oder Scrum Master übernommen, oder begleiten als Führungskraft ein Team, das Scrum neu eingeführt hat. Sie sehen große Chancen im Einsatz von Scrum, sind sich aber unsicher, ob Sie das volle Potential von Scrum für sich nutzbar machen können. Vielleicht haben Sie auch schon einiges an Erfahrung sammeln können und fragen sich, wie Sie Ihre Rolle noch besser ausfüllen können.
Rollencoaching setzt genau dort an, wo fixe Trainingsangebote keinen nennenswerten Mehrwert mehr bieten.
Wir beleuchten mit Ihnen Ihre ganz besondere Situation und reflektieren mit Ihnen Ihre Stärken und Potentiale. Gerne helfen wir Ihnen auch, Werkzeuge und Praktiken zu finden, die für Ihren Kontext besonders geeignet erscheinen, und bieten dazu gezielte Micro-Training-Sessions an, die Ihnen dabei helfen, deren Eignung zu prüfen und die Umsetzung in der Praxis zu realisieren.
Viele Führungskräfte geben nicht gerne Feedback, weil es Ihnen unangenehm ist und sie nicht wissen, wie man konstruktiv Feedback gibt.
Feedback ist jedoch ungemein wichtig für die Entwicklung von Individuen und Teams.
Die Management 3.0-Praktik „Feedback Wraps“ bietet ein erprobtes “Rezept” für konstruktives, wertschätzendes Feedback.
Eine unangenehme Situation
Heute ist definitiv nicht Martins Tag. Er hat verschlafen, weil seine Kinder vor ihm wach waren und den Wecker ausgeschaltet haben. Sein Morgenkaffee fiel deswegen auch aus. Der alltägliche Stau auf dem Weg zur Arbeit fühlte sich heute auch länger an als sonst. Kurz vor neun kommt Martin endlich im Büro an. Gerade noch rechtzeitig vor einem wichtigen Kundentermin. Doch als er den Konferenzraum betritt, trifft ihn der Schlag: Der Tisch ist übersät mit leeren Pizzakartons, benutzen Servietten und Bierdosen. Zeit zum Aufräumen bleibt nicht. Er bittet den Kunden also in sein enges Büro und bespricht seine Präsentation am Bildschirm. Eine armselige Vorstellung. Nach dem Termin sucht er nach dem Verursacher des Chaos und wird prompt fündig: Tom, der Teamleiter der Webentwicklung, ist gerade dabei mit einem seiner Mitarbeiter den Konferenzraum zu säubern. Wütend platzt Martin herein und schreit: „Verdammt, Tom! Wegen deiner Schlampigkeit habe ich einen wichtigen Kunden verloren! Grandiose Show, Tom!“ – Tom wiederum reagiert gereizt: „Fahr runter, du Spaßbremse! So schlimm kann es schon nicht gewesen sein!“
Feedback führt oft in die kommunikative Sackgasse
Haben Sie Verständnis für Martins Reaktion? Können Sie mitfühlen, was ihn ihm vorgehen muss? Tatsächlich hat Martin jeden Grund, verärgert zu sein. Und dennoch stößt dies bei Tom auf wenig Verständnis. Durch Martins Zuschreibung „Du bist schlampig“ und die Schuldzuweisung „Durch dich habe ich einen wichtigen Kunden verloren“ bringt er Tom prompt in eine Abwehrhaltung, durch die er deutlich macht, dass weitere Argumente auf der Sachebene vermutlich fruchtlos bleiben werden. Doch wie hätte Martin sein Feedback formulieren können, so dass es durch Tom auch angenommen werden kann?
Als ein gängiges Instrument, um Feedback besser verdaulich zu machen wird oft das Feedback-Sandwich angewandt. Dahinter steckt die Idee, die eigentliche Kritik, also die Wurst- oder Käsescheibe des Sandwiches, zwischen Lob zu Beginn und Ende des Gesprächs zu packen, also quasi die Brotscheiben. In unserem Beispiel könnte Martin also zu Tom sagen: „Hey, Tom! Ich finde es total klasse, dass Du hier im Laden auch mal für gute Stimmung sorgst. Dass ich heute einen wichtigen Kundentermin nicht im Konferenzraum abhalten konnte, weil Du hier ein solches Chaos hinterlassen hast, hat mich hingegen sehr gestört. Dennoch ist es super, dass Du jetzt wieder für Ordnung sorgst.“ Doch, was glauben Sie? Wird dies bei Tom die gewünschte Einsicht erzeugen? Das Problem am Feedback-Sandwich ist, dass es als rhetorisches Stilmittel mittlerweile hinlänglich bekannt ist, so dass der Empfänger des Feedbacks sich zurecht fragt, ob die beiden Lob-Brotscheiben ernst gemeint sind. Am Ende bleibt eben doch nur die Kritik im Raum stehen, die, gerechtfertigt oder nicht, meist negativ aufgefasst wird. Wer wird schon gerne auf Fehler, bzw. als unangenehm wahrgenommenes Verhalten aufmerksam gemacht. Mein Appel lautet daher…
Vergessen Sie das Feedback-Sandwich! Rollen Sie lieber einen Feedback-Wrap!
Jurgen Appelo entwarf in seinem Buch Managing for Happiness als bessere Alternative zum Feedback-Sandwich den Feedback-Wrap, der in seinem Aufbau dem Grundmuster der Gewaltfreien Kommunikation (GFK) nach Marshall B. Rosenberg folgt.
Beschreiben Sie Ihren Kontext.
Beginnen Sie die Konversation damit, dass Sie Ihre Situation erläutern, um das Verständnis und die Anerkennung Ihres Gesprächspartners gewinnen. „Tom! Ich befinde mich gerade in recht rauem Fahrwasser. Unsere Verkaufszahlen sind stark gesunken und ich muss dringend neue Kunden gewinnen.
Teilen Sie Ihre Beobachtungen mit.
Beschränken Sie sich auf spezifische Situationen, die Sie wahrgenommen haben. Vermeiden Sie Wertungen und Zuschreibungen.
„Heute morgen fand ich den Konferenzraum unaufgeräumt vor. Auf den Tischen lagen leere Pizzakartons und Bierdosen.“
Drücken Sie Ihre Gefühle aus.
Lassen Sie Ihren Gegenüber wissen, was diese Beobachtung in Ihnen auslöst. Erzeugen Sie Achtsamkeit dafür, was sie bewegt, ohne jemanden zu beschuldigen.
„Der Anblick hat mich schockiert und ein kleines bisschen in Panik versetzt, da ein wichtiger Kunde bereits an der Lobby wartete.“
Zeigen Sie auf, welche Ihrer Werte dies verletzt.
Erläutern Sie Ihre Bedürfnisse, denn für Ihren Gegenüber mag dies nicht offensichtlich sein.
„Es ist mir wichtig, wie wir unsere Firma Kunden gegenüber präsentieren. Die Präsentation in meinem engen Büro am Bildschirm zu halten, war glaube ich keine gute Vorstellung.“
Enden Sie mit Vorschlägen.
Lassen Sie Ihrem Gegenüber Raum, die Situation zu verbessern und die Lücke zwischen den Fakten und Ihren Bedürfnissen zu schließen. Machen Sie ruhig Vorschläge.
„Ich wünsche mir, dass wir einen Weg finden, die Situation zu verbessern. Wie wäre es, wenn Du mir zukünftig rechtzeitig Bescheid gibst, wenn so etwas noch mal passiert, so dass ich einen anderen Raum buchen kann!?“
Hören Sie zu.
Und schließlich: Hören Sie Ihrem Gesprächspartner aufmerksam zu, wie sie die Situation wahrgenommen hat und welche Vorschläge gemacht werden. In unserem Beispiel könnte Tom vielleicht nun so reagieren: „Oh, Martin. Das tut mir leid! Ich wollte Dir ganz sicher nicht deinen Kundentermin sabotieren. Weißt Du, meine Jungs haben in letzter Zeit für die neue Webseite echt ranklotzen müssen. Ohne Murren haben Sie jeden Tag ein bisschen länger gearbeitet und auch tatsächlich Erfolg gehabt. Die neue Seite ist seit gestern Mittag live. Zur Feier des Tages habe ich spontan eine kleine Movie Night organisiert und Pizza und Bier spendiert. Ich weiß auch nicht mehr, warum wir dachten, dass es eine gute Idee sei, die komplette Original Star Wars-Trilogie zu schauen. Auf jeden Fall wurde es sehr spät, weshalb ich das Aufräumen auf heute Morgen verlegt habe. Aber versprochen: Es soll nicht wieder vorkommen!“
Burn-down Chart Ein Burn-down Chart bildet die Menge unerledigter Arbeiten eines Sprints oder Releases ab. Die Zeit wird dazu auf der horizontalen Achse und die verbleibende Arbeit auf der vertikalen Achse dargestellt. Der Arbeitsfortschritt wird regelmäßig im Chart als (typischerweise fallende) Linie eingetragen. Der Arbeitsaufwand kann auf unterschiedliche Arten quantifiziert werden, wie zum Beispiel durch Anzahl der Aufgaben, geschätzte Entwickler-Stunden, aber auch Story Points oder Function Points. Das Burn-down Chart dient dem Scrum Team als Werkzeug zur Inspektion des Arbeitsfortschritts und kann auch gut zur Information der Stakeholder eingesetzt werden. Siehe auch Burn-up Chart.
Burn-up Chart Ein Burn-up Chart bildet die Menge erledigter Arbeiten eines Sprints oder Releases ab. Die Zeit wird dazu auf der horizontalen Achse und die kumulierte Arbeitsleistung auf der vertikalen Achse dargestellt. Der Arbeitsfortschritt wird regelmäßig im Chart als aufsteigende Linie eingetragen. Der Arbeitsaufwand kann auf unterschiedliche Arten quantifiziert werden, wie zum Beispiel durch Anzahl der Aufgaben, geschätzte Entwickler-Stunden, aber auch Story Points oder Function Points. Das Burn-up Chart dient dem Scrum Team als Werkzeug zur Inspektion des Arbeitsfortschritts und kann auch gut zur Information der Stakeholder eingesetzt werden. Siehe auch Burn-down Chart.
Daily Scrum Tägliches Scrum-Ereignis mit 15-minütiger Timebox für das Entwicklungsteam, um die Entwicklungstätigkeiten des Tages zu planen. Bei Planänderungen wird das Sprint Backlog aktualisiert. Siehe auch Scrum-Ereignisse.
Definition of Done Gemeinsames Verständnis über die Mindestanforderungen an ein Produktinkrement um veröffentlicht werden zu können. Die Definition of Done wird unter Berücksichtigung von Organisationsvorgaben vom Entwicklungsteam erstellt und gepflegt.
Development Team Englischer Begriff für Entwicklungsteam.
DoD Abkürzung für Definition of Done.
Emergenz Emergenz bezeichnet die Möglichkeit der Herausbildung von neuen Eigenschaften oder Strukturen eines Systems infolge des Zusammenspiels seiner Elemente. Scrum-Artefakte sind emergent; d.h. dass sie sich über Zeit verändern auf Grund der Erkenntnisse und Einsichten, die die beteiligten Akteure aus dem Umgang mit diesen ziehen. Siehe auch https://de.wikipedia.org/wiki/Emergenz
Empirie Bei der empirischen Prozesssteuerung wird nur die Vergangenheit als sicheres Faktum akzeptiert. Entscheidungen basieren auf Beobachtungen, Erfahrungen und Experimenten. Drei Säulen tragen jede empirische Prozesssteuerung: Transparenz, Überprüfung und Anpassung.
Entwicklungsteam Eine Rolle innerhalb des Scrum Teams. Das Entwicklungsteam ist verantwortlich für die Planung und Durchführung aller notwendigen Entwicklungstätigkeiten zur Erstellung eines releasefähigen Produktinkrements (mindestens) am Ende eines jeden Sprints. Siehe auch Scrum-Rollen.
Forecast Englischer Begriff für Prognose.
Inkrement Siehe Produkt Inkrement.
Iteration Eine Iteration wird in Scrum Sprint genannt.
Product Backlog Das aktuelle Verständnis über die notwendigen Arbeiten zur Erstellung, Betrieb, Pflege und Weiterentwicklung eines Produkts. Das Product Backlog wird vom Product Owner verwaltet.
Product Backlog Grooming Nicht mehr verwendeter Begriff; ersetzt durch Product Backlog Refinement.
Product Backlog Refinement Regelmäßig durchgeführte Aktivität, bei der Product Owner und Entwicklungsteam Details zu Product Backlog Einträgen hinzufügen. Dieser Vorgang wurde in früheren Versionen des Scrum Guides auch als Product Backlog Grooming bezeichnet.
Product Owner Die Scrum-Rolle, die für die Maximierung des Werts eines Produkts verantwortlich ist. Product Owner formulieren die geschäftlichen und fachlichen Erwartungen an das Produkt und vertreten diese gegenüber dem Entwicklungsteam. Siehe auch Scrum-Rollen.
Produktinkrement Ein Stück fertiger Software, dass Funktionalität zu bereits früher fertiggestellten Inkrementen hinzufügt, wobei die Summe aller Inkremente zusammen ein ein Produkt formen.
Prognose Auswahl von Einträgen aus dem Product Backlog, die das Entwicklungsteam innerhalb eines Sprints für realisierbar erachtet.
Scrum Ein Rahmenwerk für die agile Entwicklung komplexer Produkte. Scrum wurde von Ken Schwaber und Jeff Sutherland entwickelt und 1995 der Öffentlichkeit vorgestellt.
Scrum Board Ein physisches Board zur Visualisierung des Sprint Backlogs. Scrum Boards sind ein optionales Werkzeug in Scrum.
Scrum Guide Die Definition von Scrum, geschrieben und zur Verfügung gestellt von Ken Schwaber und Jeff Sutherland, den Mitbegründern von Scrum. Diese Definition besteht aus den Rollen, Ereignissen, Artefakten von Scrum und den Regeln, die sie miteinander verbinden. Siehe auch https://www.scrumguides.org/.
Scrum Master Die Scrum-Rolle, die für Beratung, Coaching, Training und Unterstützung eines Scrum Teams und dessen Umfeld verantwortlich ist. Scrum Master stellen sicher, dass Scrum richtig verstanden und angewendet wird. Siehe auch Scrum-Rollen.
Scrum Team Ein selbstorganisierendes Team, bestehend aus einem Product Owner, dem Entwicklungsteam und einem Scrum Master. Siehe auch Scrum-Rollen.
Scrum-Ereignisse Der Scrum Guide beschreibt 5 Ereignisse: Sprint, Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospektive.
Scrum-Events Englischer Begriff für Scrum-Ereignisse.
Scrum-Roles Englischer Begriff für Scrum-Rollen.
Scrum-Rollen Scrum definiert drei Rollen: Product Owner, (Mitglied des) Entwicklungsteam und Scrum Master. Zusammen formen diese ein Scrum Team.
Scrum-Values Englischer Begriff für Scrum-Werte.
Scrum-Werte Grundwerte, die dem Scrum Rahmenwerk zu Grunde liegen: Selbstverpflichtung (Engagement), Mut, Fokus, Offenheit und Respekt.
Selbstorganisation Der Scrum Guide definiert Selbstorganisation als ein Managementprinzip, nachdem Teams ihre Arbeit autonom planen, organisieren und durchführen innerhalb klar definierter Grenzen und Zielsetzungen.
Sprint Ereignis mit feststehender maximal 1-monatiger Länge, das als zeitlicher Rahmen für die anderen Scrum-Ereignisse dient. Sprints werden nacheinander, ohne Zwischenräume, durchgeführt.
Sprint Backlog Eine Übersicht über die Menge zu erledigender Entwicklungstätigkeiten um ein Sprintziel zu erreichen. Das Sprint Backlog wird vom Entwicklungsteam verwaltet.
Sprint Goal Englischer Begriff für Sprintziel.
Sprint Planning Ein zeitgebundenes Scrum-Ereignis von maximal 8 Stunden, um einen Sprint zu starten. Während des Sprint Planning formuliert das Scrum Team ein Sprintziel, wählt Einträge aus dem Product Backlog aus, die auf dieses Ziel einzahlen, und erarbeitet ein Sprint Backlog, um das Sprintziel zu realisieren. Siehe auch Scrum-Ereignisse.
Sprint Retrospective Ein zeitgebundenes Scrum-Ereignis von maximal 3 Stunden, um einen Sprint zu beenden. Während er Sprint Retrospektive inspiziert das Scrum Team seine Arbeitsweise und Prozesse mit dem Ziel, Maßnahmen zur Optimierung dieser für den kommenden Sprint abzuleiten. Siehe auch Scrum-Ereignisse.
Sprint Review Ein zeitgebundenes Scrum-Ereignis von 4 Stunden oder weniger, um die Entwicklungsarbeit eines Sprints abzuschließen. Es dient dem Scrum-Team und den Stakeholdern dazu, das aus dem Sprint resultierende Produktinkrement zu überprüfen und das Product Backlog bei Bedarf anzupassen. Siehe auch Scrum-Ereignisse.
Sprintziel Der (oft geschäftlich oder fachlich orientierte) Zweck eines Sprints. Auswahl und Menge der Entwicklungstätigkeiten eines Sprints können während eines Sprints angepasst werden, um das Sprintziel zu erreichen.
Stakeholder Personen mit Interesse an und Wissen über das Produkt, das vom Scrum Team entwickelt wird. Stakeholder helfen dem Scrum Team dabei das Produkt inkrementell zu erforschen und zu entwickeln.
Storypoint Auf der Fibonacci-Folge basierende Metrik, die verwendet wird, um die Größe von Arbeitspaketen relativ zu einander in Beziehung zu setzen. Vorhersagen über den Zeitpunkt der Fertigstellung können dann mit Hilfe der Velocity gemacht werden. Diese Praktik hat ihren Ursprung im Extreme Programming (XP) und kann in Scrum optional verwendet werden.
User Story Eine spezielle Form der Anforderungsdokumentation, oft in der Form „Als möchte ich , um zu erzielen“. Die User Story hat ihren Ursprung im Extreme Programming (XP) und kann in Scrum optional verwendet werden.
Velocity Anzahl von Storypoints, die ein Entwicklungsteam in den letzten Sprints (durchschnittlich) fertiggestellt hat. Diese Praktik hat ihren Ursprung im Extreme Programming (XP) und kann in Scrum optional verwendet werden.
Scrum ist streng genommen keine Methode, sondern ein Rahmenwerk, welches im Agilen Umfeld eingesetzt wird. Doch was bedeutet das genau? Bei Scrum geht es vorallem um die Selbstorganisation der Teams. Statt wie im klassischen Projektmanagement auf einen Projektmanager zu setzen, der alle Entscheidung für das Team trifft, sind bei Scrum alle Teammitglieder gleichberechtigt und können selbst darüber entscheiden, wie die Aufgaben, die für das Projekt entstehen, verteilt werden. Natürlich gibt es dafür auch Regeln, allerdings bilden diese den schon erwähnten Rahmen, an denen sich das Team orientieren kann. Die Scrum-Regeln sind relativ einfach und können zudem individuell an die Bedürfnisse und Gegebenheiten der Organisation und den Teams angepasst werden.
Was ist der Sprint?
Ein wichtiger Aspekt bei Scrum ist der Sprint. Er ist die wichtigste Zeiteinheit und gibt die Taktung vor. Meist wird eine Sprint auf zwei oder drei Wochen gesetzt – Varianten sind hier jedoch möglich. Wichtig dabei: Jeder Sprint muss immer gleich lang sein. Entschieden wird dann darüber, welche Aufgaben das Scrum-Team innerhalb dieser Zeit bewältigen kann – am Ende sollte ein release-fähiges Resultat stehen. Doch auch ein “Scheitern” ist vorgesehen: Ist das Sprint-Ziel nicht erreichbar, wird dies am Ende des Sprints besprochen und die Aufgaben entsprechend neu justiert. Anpassen an Gegebenheit, inspizieren der Arbeit und damit das Erkennen und Ausmerzen von Hindernisse – das ist agiles Arbeiten.
Was sind die Scrum-Rollen?
Jeder hat in Scrum seine Rolle – doch diese sind nicht wie im klassischen Projektmanagment fest durch den Jobtitel definiert. Es gibt im Grund nur drei Scrum-Rollen: Den Product Owner, den Scrum Master und die Teammitglieder. Das macht die Aufgabenverteilung übersichtlich und nimmt Komplexität. Überhaupt geht es bei Scrum vorallem um die Reduktion von Komplexität – damit sich jeder voll auf seine Aufgabe konzentrieren kann.
Was macht ein Product Owner?
Der Product Owner gibt im Scrum-Team die Vision des Projekts vor. Bei dieser Rolle geht es darum, die Aufgaben zu sortieren und zu strukturieren. Ein Product Owner entscheidet darüber, was der “Backlog”, also der gesamte Aufgabenkatalog beinhaltet, zudem ist die Priorisierung der Tasks ein wichtiger Aspekt. Bei den täglichen Meetings, den “daily Scrums” ist diese Rolle jedoch nicht vertreten – der Product Owner hat keinen Einfluss darauf, wie das Scrum-Team die Aufgaben angeht und kann auch nicht in den laufenden Scrum Prozess eingreifen.
Was macht ein Scrum Master?
Der Scrum Master für einen reibungslosen Ablauf im Scrum-Team. Er ist die kommunikative Brücke zum Product Owner und sorgt dafür, das alle Regeltermine zeitig begonnen und beendet werden. Dies vereinfacht die Meetings und Termin im Scrum-Team und sorgt dafür, das jeder im Scrum-Team weiß, wann welcher Termin ansteht.
Was macht das Scrum-Team?
Das Scrum-Team setzt operativ den festgelegten Backlog um. Dabei sucht das Scrum-Team die einzelnen Aufgaben selbst zusammen und entscheidet darüber, welche “Items”, also Teile des finalen Produkts es umsetzen möchte.
Was ist der Untschied zwischen Scrum und Kanban?
Scrum dient in der Software-Entwicklung dazu, klare Prozesse einzuführen, die Komplexität zu reduzieren und jeder Rolle zu ermöglichen, das beste Ergebnis zu liefern. Kanban hingegen ist “evolutionäres Change-Management” – hier werden die Prozesse nach und nach optimiert sowie angepasst.
