Skip to content
All posts

V wie Valuable: Geld ist nicht alles, was zählt

Die INVEST-Kriterien behandeln vor allem den Wert von User Storys. Was ist aber mit den anderen Backlog Items wie z.B. Bugfixes, Explorationen, Maßnahmen aus der Retrospektive? In welche Wert-Ausprägungen wirken diese Backlog-Items hinein und welche Erscheinungsformen von Wert gibt es überhaupt?

Der Scrum Guide 2016[1] liefert bei einer Suche nach dem Wort „Value“ 14 Treffer. Alle Rollen sind in der einen oder anderen Situation besonders aufgefordert, Wert zu liefern.

Wenn man über Wert nachdenkt, kommen oftmals zunächst finanzielle Werte in den Sinn. Wert kann jedoch in vielen Erscheinungsformen auftreten. Der Product Owner muss entscheiden, an welchen Themen die Ressourcen des DevTeams am besten eingesetzt sind. Dazu muss er/sie die Ausprägungen von Wert kennen und vor allem ein Verständnis für die Themen entwickeln, die keine User Storys, Features oder Epics sind. Wie ist z.B. eine Refaktoring Maßnahme zu bewerten? Ist es wertvoller, im nächsten Sprint einen Bugfix anzugehen oder sollte einer Exploration zu einer neuen Technologie der Vorzug gegeben werden?

In untenstehender Tabelle habe ich verschiedene Ausprägungen von Wert aus Business-Sicht und aus Sicht des ScrumTeams aufgelistet, ohne den Anspruch auf Vollständigkeit zu erheben. Diese Aufstellung soll dabei helfen, ein weitgefasstes Verständnis von wert-vollen Themen herbeizuführen.

Kategorie Aus Business Sicht Aus Sicht des ScrumTeams
Neue Kunden, neue Märkte
  • Wert durch Erweitern der Produkt Linie
  • Reduzierung der Kosten von Verzögerungen bei Produkteinführungen
 
Wert durch Zusatzverkäufe
  • Neue Features führen zu mehr verkaufte Einheiten oder Lizenzen
  • Neue Features ermöglichen einen höheren Preis pro Einheit
 
Immaterielle Werte
  • Ausbau von Reputation
  • Marketingmaßnahmen
  • Zeiteinsparungen
  • Kürzere Time-to-Market
  • Nutzen von Opportunitäten
  • Neue Handlungsoptionen basierend auf neuen Kompetenzen des Unternehmens
  • Unterstützung des Unternehmensziels
  • Besserer Service
  • Garantien
  • Behobene Fehler
  • Verbessern der Zusammenarbeit
  • Wissenstransfer im Team
  • Auflösen von Impediments
  • Aneignen neuer Kompetenzen
  • Verringern der technischen Schulden
  • Flexibilität in der Software (Übertragbarkeit, Anpassbarkeit)
  • Umsetzung von Verbesserungsmaßnahmen
  • Automatisierung von Tätigkeiten
Wert durch Risiko-Reduzierung
  • Validierung von Hypothesen zu Markt und Usern
  • Validierung von techn. Annahmen
  • Wissenszuwachs
Wert durch operative Einsparungen
  • Prozessverbesserung
  • Kosteneinsparung
  • Vermeidung von Strafen durch Erfüllen von Regularien und Vorgaben
  • Reduzierung des Wartungsaufwandes

 

Andere Quellen beschäftigen sich ebenfalls mit dem Wert in Software und im Software-Entwicklungsumfeld, siehe hierzu:

Agile42. „www.agile42.com.“ 10. 05 2017. http://www.agile42.com/en/agile-coaching-company/agile-scrum-tools/business-value-game/ (Zugriff am 09. 05 2017).

Gottesdiener, Ellen. „www.ebgconsulting.com.“ 14. 12 2016. https://www.ebgconsulting.com/blog/factors-for-making-value-based-product-decisions/ (Zugriff am 10. 05 2017).

Scrum Inc. „www.scruminc.com.“ 20. 07 2014. https://www.scruminc.com/calculating-business-value/ (Zugriff am 10. 05 2017).

Wake, Bill. „www.xp123.com.“ 03. 01 2013. http://xp123.com/articles/valuable-stories-in-the-invest-model/ (Zugriff am 10. 05 2017).

[1] http://www.scrumguides.org/scrum-guide.html