Outcome vs. Output (mit Beispiel aus Scrum)

Output vs. Outcome
Von Sebastian Schneider // 24.09.2021 // 0 Kommentare

Output und Outcome sind zwei verschiedene Dinge, werden aber gerne und oft fälschlicherweise als Synonym verwendet. Gerade wenn wir in Scrum auf das Legendary Agile Dream Team und Teams generell fokussieren, ist es ganz entscheidend, dass du den Unterschied kennst.

Output

Ein Output ist etwas, das wir mal grundsätzlich innerhalb eines Teams vorfinden. Wenn du so möchtest, kann ein Team selbst damit etwas anfangen, der Kunde weniger. Ein Output für sich genommen, ist für Außenstehende wenig aussagekräftig bzw. wertig.

Du kannst dir den Output auch als Aufgabe oder das Erreichen von einzelnen Tätigkeiten vorstellen. Die Aufgabe "Klasse XY überarbeiten" ist eine typische Aufgabe, die deinem Kunden nichts nutzt. Oft kann er damit gar nichts anfangen. Du im Team kannst mit diesem Output etwas anfangen, du befasst dich mit den Details.

Wenn du in einem Projekt klassische Projektmanagementartefakte, wie zum Beispiel phasenorientierte Meilensteine nutzt, dann sind das ebenfalls Outputs. Eine Phase wie "Anforderungsbeschreibung fixiert" ist ebenso ein Ergebnis mit dem kein Kunde etwas anfangen kann, jedenfalls nichts im eigentlichen Sinne des Wertes (natürlich weiß er dann, dass diese Phase vorbei ist, aber nicht mehr).

Es ist möglich ganz viel Output zu erzeugen, ohne einen Mehrwert für den Kunden zu generieren. Aus diesem Grunde nutzen wir in Scrum gerne User Stories (auch wenn sie keine Pflicht im Framework sind), um den Benutzer in den Mittelpunk zustellen und auf den Outcome zu fokussieren.

Outcome

Ein Outcome versetzt den Kunden in die Lage etwas mit einem Ergebnis des Teams zu tun. Das ist ein wichtiger Unterschied. Der Kunde bekommt ein Ergebnis und ist damit in der Lage etwas (oft eine Aufgabe, ein Problem, etc) zu lösen oder zu bearbeiten. Wenn wir eine richtige iterative, inkrementelle Entwicklung auf die Beine gestellt haben, dann nennen wir das Inkrement. Wir können auch sagen, wir befähigen den Kunden dann aktiv etwas zu tun. Das kann ein Outcome aber nicht ein Output leisten.

Der Kunde muss kein Endkunde sein. Ein anderes Team ist ebenso möglich und jede Person, die dieses Ergebnis dann nutzen kann.

Beispiel in Scrum: Output vs Outcome

Wenn du in Scrum deine Sprints richtig gestaltet hast und am Ende in der Lage bist ein (Produkt-)Inkrement zu erzeugen, dann ist das ein Outcome. Alle Aufgaben innerhalb deines Sprints hingegen zählen zu den Outputs. Wenn du in deinem Sprint Backlog mit dem Team Aufgaben geschrieben hast, dann zählen diese zu den Outputs.

Schreibst du gute User Stories, dann ist die Wahrscheinlichkeit hoch jemanden mit dem Outcome dieser User Story zu befähigen.

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

>