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.

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)

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.

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.

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.

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.

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.