Bitte geben Sie einen Grund für die Verwarnung an
Der Grund erscheint unter dem Beitrag.Bei einer weiteren Verwarnung wird das Mitglied automatisch gesperrt.
Ergebnisse messen
Ich habe keinen besseren Bereich gefunden und hoffe daher dass das hier o.k. ist.
Messt ihr eure Ergebnisse und wenn ja:
- Wie messt ihr sie? Evtl. über Story Points oder Down Break Charts? (Ich habe mit beidem keine Erfahrung)
- Wann messt ihr sie? In der Demo oder vielleicht sogar Retro?
Ich überlege gerade, ob ich so was in der Art einführen möchte.
#2
Bei mir werden die Storys in Story Points geschätzt und dann ganz klassisch mit Break Down Chart dargestellt.
Eine weitere Variante ist einfach die Anzahl der erledigten Storys (ohne Schätzung) je Sprint darzustellen.
Die Messung erfolgt, wenn der Sprint geschlossen wird (geplant vs. erledigt).
Grundsätzlich ist das Messen eine gute Idee aber bei der Einführung solltest Du sehr sensibel rangehen und vorher mit dem Deinem Team sprechen. Das Thema "Messung" ist ja leider nicht sehr beliebt...
Ich würde die Messungen auch nur erst einmal intern verwenden und nicht an das Management geben. Dort könnten die Zahlen gleich falsch interpretiert werden.
Sehe ich ganz ähnlich. Aber ich weiß auch, dass wir ja immer und überall messen sollen. Wir hatten sogar bei der ISO Zertifizierung die Diskussion mit den Auditoren.
Wie Matthias es schon geschrieben hat, erst mal intern ausprobieren und schauen, inwiefern es Sinn macht.
#4
Es hängt davon ab was für ein Framwork ihr verwendet. Bei Scrum kommt für die Messung wie oben schon geschrieben die Anzahl der erledigten Story-Points und daraus lässt sich dann die Velocity berechnen. Bei Kanban dagegen gehört Messen grundsätzlich dazu (wird bei uns aber auch nicht gemacht)
Wie messe ich denn Kanban?
#6
Für Kanban in der Softwareentwicklung gibt es eine spezielle wiki-Seite: https://de.wikipedia.org/wiki/Kanban_(Softwareentwicklung)
Gemessen wird oft die Durchflussgeschwindigkeit und die Durchflussmenge. Bei uns hat man das aufgegeben, weil die Tickets im Umfang start unterschiedlich sind.
Ja, okay ... Durchflussgeschwindigkeit könnte Sinn machen. Wie du aber auch schon schreibst, muss es dann aber auch erst einmal vergleichbar sein.
#8
Ich denke beide Grössen machen Sinn.
Das eine sagt ja aus, wie schnell eine Reaktion ist, also wenn ich jetzt vorne ein Ticket reingebe, wie lange dauert es ungefähr bis es fertig ist.
Das andere gibt an wieviel Tickets pro Zeiteinheit durchkommen.
Die zwei Grössen können sehr unterschiedlich sein. Wenn du z.B. einen Porsche nimmst für einen Transport dann ist die Durchflussgeschwindigkeit hoch, aber die Durchflussmenge klein. Bei einem LKW ist es umgekehrt. So ähnlich kann es auch in der Softwareentwicklung sein.
Die Erklärung gefällt mir ... Danke!
Danke erst einmal an euch alle.
Das Schätzen bzw. Bewerten über Story Points finde ich absolut sinnvoll. Anfangs war das auch der Plan gewesen. Als man gemerkt hat dass das gar nicht so einfach ist, ist das aber eingeschlafen. Leider nehmen das die PO´s dann auch nicht so eng, wenn Stories nicht bearbeitet wurden. Das ist der Nachteil wenn nicht gemessen wird.
Wollen tut das natürlich niemand. Aber ich denke trotzdem dass und das mal gut tun würde.
Ich habe viel Story Points verwendet, allerdings nicht zum "Messen" sondern nur zum Schätzen. Ich finde die Einheit sehr gut, um relativ schnell in einem Team zu einer Schätzung zu kommen und die Fibonacci-Reihenfolge stellt meiner Erfahrung nach gut dar, wie die Ungenauigkeit steigt bei zunehmender Größe/Komplexität/Unsicherheit.
Falls Story Points für das Messen von Leistung verwendet werden, dann gibt es unsägliche Diskussionen, denn natürlich passen Schätzungen nicht immer zum tatsächlichen Aufwand. Und dann? Schätzungen nachträglich verändern, damit die Velocity nicht fällt?? Immer größer Schätzen, damit die Velocity nicht fällt?? Meine Erfahrung ist, dass je größer der Druck in diese Richtung geht, desto mehr wird an den Zahlen manipuliert, nur um sich nicht rechtfertigen zu müssen und dann werden es in 'agile Kartons' verpackte Aufwandsschätzungen mit viel Puffer.
Man muss sich also entscheiden, denke ich. Entweder es ist eine Schätzgröße, um zukünftige Sprints mit wenig Schätzaufwand grob vorausplanen zu können (in der Form, dass ein Product Owner sagen kann: "Nach der Schätzung meines Teams müssten wir in knapp 2 Sprints mit dem Feature fertig sein. Wenn ich dem Kunden 3-4 Sprints verspreche, müsste ich definitiv auf der sicheren Seite."), oder es ist nur ein anderer Name für Personentage (PT) und ein Teil eines Wasserfall-Arbeitsplans."
Falls die Ergebnisse/Velocitys zu stark schwanken oder sich sehr stark verändern, wäre das für mich definitiv ein Punkt für die Retrospektive. Zum einen könnten hinter diesen Änderungen Probleme des Teams stecken, mit welchen sich das Team befassen oder sie zumindest kennen sollte oder der Product Owner bekommt Probleme mit seinen Versprechen/Vorhersagen an die Außenwelt und es muss eine Unterstützung für den Product Owner gefunden werden, dass er realistischere Aussagen nach außen hin treffen kann.
Die meisten Coaches bzw. Scrum Master sind wohl eher gegen das Messen von Ergebnissen. Nur wird dies oftmals von Geschäftsführung/Management usw. nicht als ausreichend gesehen. Ich habe bislang die Erfahrung gemacht, dass die Mittel, die in diese Methoden gesteckt werden irgendwann als Savings gesehen werden müssen. Das hat nichts mit Mindest und Kulturwandel zu tun - ist mir volkommen klar. So tickt aber die Industrie/Wirtschaft.
Ich habe sogar schon mal erlebt, dass Berater im Management erklärt haben, dass ein AC daran gemessen wird, wie schnell in seinen Teams sind Anzahl erreichter Story-Points gesteigert wird. Mit solchen Aussagen wird die Sachen eben auch nicht einfacher.
Für mich ist hier eine interessante Frage, was man denn an einem "Ergebnis" wissen/messen will! Will ich nur den Aufwand wissen, dann reicht meist ein Blick in den Stundenzettel. Der sagt mir aber nicht, ob ich gut/schnell/effizient gearbeitet habe, ob meine Testabdeckung/Qualität gut ist oder ob ich es vermieden habe, technische Schulden aufzubauen und er sagt mir erst recht nicht, was denn die Arbeit Wert ist oder wer der bessere Mitarbeiter ist.
Verfolgt der Product Owner mit seinen Features Mehrwert, der gemessen werden kann, dann ist das die viel spannendere Fragen... also wieviel Personen wandern auf meine Website... wieviele Kunden verwenden eine neue Funktionalität... wie lange braucht ein Kunde im Schnitt, um einen Bestellvorgang abzuschließen... das wären für mich viel sinnvollere Messwerte, die dem Product Owner Rückmeldung geben können, ob die umgesetzten Features sinnvoll waren.
Stimmt, die Frage muss konkreter gestellt sein.
Auf mich kommen immer wieder Manager zu und fragen:
"Wie kann ich messen, ob ich mit agilen Arbeitsweisen effizienter werde?"
"Werden wir mit Scrum besser?"
usw. ...
Solche Dinge wollen viele messbar machen. Dies ist aus meiner Erfahrung kaum möglich. Zumindest wenn ich das Wort "messen" mit KPIs verbinde.
Aus der Controller Sicht schon auf nachvollziehbar. Wir stecken Kapa in Form von Coaches und Meetings rein und wollen natürlich auch sehen, was unterm Strich dabei herauskommt.
Ja, ich kenne diese Fragen.
"Wie kann ich messen, ob ich mit agilen Arbeitsweisen effizienter werde?"
Wenn ich eine veränderte Arbeitsweise messen will, dann muss ich ja wissen, warum ich Agile eingeführt habe - was wollte ich ursprünglich verbessern? Dann muss ich >geeignete< Vergleichsmetriken haben, um zu dieser Frage eine Aussage treffen zu können.
Wollte ich die Lead Time verbessern von Fachbereich beauftragt etwas dringendes bis Software ist in Produktion? Das kann man messen.
Wollte ich die Qualität verbessern z.B. durch Testautomatisierung? Hier könnte ich Defects/Bugs vergleichen... ist nicht leicht, da Einstufung oder allein die Frage ob es ein Defect oder eine neue Anforderung ist, nicht einfach zu beantworten ist.
Wollte ich den Aufwand für Umsetzungen verringern (also den schnelleren Wasserfall machen)? Hier kann man meist gar nichts messen. Man hat aus der Vergangenheit grob die Anzahl an Personentagen, meist vermischt mit Meetings, Defect Fixing und anderen Nebentätigkeiten. Die gleiche Anforderung unter den gleichen Umständen mit der gleichen Software in der gleichen Größe und der gleichen Mannschaft wird man nicht mehr als einmal durchführen können.
Wollte ich den Overhead verbessern der entsteht, wenn Fachkonzeption an Entwicklung, die an Test übergibt und sich dann alle treffen und merken, dass Fachkonzeption etwas anderes wollte? Hier hat man meist keine Zahlen aus der Vergangenheit und selbst wenn, was genau will man messen? Die Anzahl/Zeit der Absprachemeetings? Die Anzahl/Zeit der nachträglichen Korrekturen? Selbst wenn man das vergleichen würde, würde man immer noch berücksichtigen müssen, ob man den gleichen Mehrwert erzeugt hat. Auch nicht leicht. Aber man kann natürlich die Teams fragen durch grobe Umfragen (dazu müsste man die gleichen allerdings auch vorher gemacht haben).
"Werden mir mit Scrum besser?"
Hier würde ich mit der Gegenfrage antworten, warum Scrum denn eingeführt wurde (s.o.) und dann überlegen, ob man das bestätigen oder widerlegen kann.
Aus meiner Erfahrung ist der IST-Stand bei vielen Unternehmen so, dass sie für die Vergangenheit ganz grob sagen können, welche Beauftragung wie viel Aufwand verursacht hat (ganz grob, weil meist Wartung durch eine Mischkalkulation abgedeckt wird etc.). Ich kenne kein Unternehmen was behauptet, dass sie pro Beauftragung sagen können, welche teuer/günstig war oder wo effizienzt/verschwenderisch gearbeitet wurde, da diese Systeme darauf getrimmt sein, Planungen einzuhalten (also lieber länger zu brauchen, damit man nicht den Vorwurf bekommt, absichtlich zu klein zu schätzen).
Die Erwartung, dass man nun etwas messen und mit früher vergleichen kann, was man noch niemals zuvor messen konnte, hat meiner Erfahrung/Meinung eher etwas mit einem 'mittleren Management' zu tun, was sich nicht ändern möchte und mit diesen Fragen eine (weitere) Veränderung blockieren möchte und es oft leider auch schafft.
- Das Forum
- Was ist Agile und für wen und was ist das Forum gedacht?
- Neues und Wichtiges
- FAQs
- Regeln
- Agile Methoden
- Kanban
- Design Thinking
- Lean Management
- DevOps
- SCRUM
- Konklave - Backlog - Backlog Refinement - Planning I
- Sprintplanung - Planning II
- Daily Standup Meeting
- Demo - Sprint Review
- Retrospektive
- Implementierung von Scrum
- Rollen
- Softskills
- Übungen zur Aktivierung von Teams
- Feedback geben, bekommen und einfordern
- Moderationstechniken
- Werkzeuge und Hilfsmittel
- Hardware
- Software
- Kennzahlen und Messmethoden
- Medien
- Youtube
- Literatur
- Artikel und Berichte
- Dokumente und Schulungsunterlagen
- Umfragen für wissenschaftliche Arbeiten
- Support und allgemein Technisches
- Support
- Ausbildungen und Veranstaltungen
- Ausbildungen, Schulungen und Workshops
- Vorträge
- Meetups
- Konferenzen und Kongresse
- Plauderecke
- Premiumbereich
Jetzt anmelden!
Jetzt registrieren!