Product Canvas - gpm-ipma.de · Product Canvas 8. Projektmanagement-Tag GPM Region Karlsruhe 3. Juli 2015 Benjamin Seidler, Mustafa Yilmaz

© 2015 andrena objects ag

Product Canvas

8. Projektmanagement-Tag

GPM Region Karlsruhe

3. Juli 2015

Benjamin Seidler, Mustafa Yilmaz

Werkzeugkasten und Tools für den Agilen Requirements Engineer


Experts in agile software engineering 3

Benjamin Seidler Mustafa Yilmaz

www.andrena.de

[email protected]


Agile Requirements Engineering 5

Agenda

• Agiles Requirements Engineering

• Business Model Canvas

• Produktvision

• Rollen, Personas und Szenarien

• User Stories & Epics

• Design-Entwürfe & Nichtfunktionale Anforderungen

Werkzeugkasten Product Canvas


• Specification by Example / Automatisierte Akzeptanztests

• Refinement & Product Backlog

• Zerlegen von User Stories

• Agiles Schätzen

• Priorisieren

• Story Maps

• Velocity & Release Planung

• Impact Mapping


Weitere Werkzeuge



Agile Requirements Engineering



Was ist Requirements Engineering (RE) ein systematischer und disziplinierter Ansatz zur Spezifikation und zum Management von Anforderungen mit den folgenden Zielen:

1. Die relevanten Anforderungen zu kennen, Konsens unter den Stakeholdern über die Anforderungen herzustellen, die Anforderungen konform zu vorgegebenen Standards zu dokumentieren und die Anforderungen systematisch zu managen.

2. Die Wünsche und Bedürfnisse der Stakeholder zu verstehen, zu dokumentieren sowie die Anforderungen zu spezifizieren und zu managen, um das Risiko zu minimieren, dass das System nicht den Wünschen und Bedürfnissen der Stakeholder entspricht.

Definition: International Requirements Engineering Board (IREB)



Agilitätsdreieck



Prinzipien hinter dem Agilen Manifest

1. Unsere höchste Priorität ist es, den Kunden durch frühe und

kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.

2. Anforderungsänderungen selbst spät in der Entwicklung willkommen

heißen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil

des Kunden.

6. Die effizienteste und effektivste Methode, Informationen an und

innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von

Angesicht zu Angesicht.



Das Projektmanagementdreieck

Vom planbasierten zum nutzwertbasierten Ansatz

Plan-basiert

Wert- basiert

Umfang

Dauer Kosten

Dauer Kosten

Umfang (durch Priorisierung)

festgelegt

geschätzt

Nach: Dean Leffingwell: Agile Software Requirements

11



Empirischer bzw. agiler Ansatz

• Iterativ, inkrementell, Just in Time.

• Überprüfen und Anpassen, Selbstorganisation

Scrum SPRINT

≤ 30 Tage 1 Tag

Product Backlog

Sprint Backlog

Product Increment



Agile Requirements Engineering – was muss es leisten?

• Wert-/Nutzenorientierung

• Iterativ und inkrementell

• Anforderungen Just-in-time

• Direkte Kommunikation



Werkzeuge des Agilen RE



Business Model Canvas



Business Model

• Geschäftsmodelle beschreiben, wie eine Organisation bzw. ein Unternehmen Mehrwert für Kunden erzeugt und einen Ertrag für die Organisation sichern kann.

• Geschäftsmodelle helfen, die Schlüsselfaktoren des Unternehmenserfolges oder -misserfolges zu verstehen, zu analysieren und zu kommunizieren.




Eine Methode zur Visualisierungen von Geschäftsmodellen

• Erarbeitung eines Geschäftsmodells für eine Firma, ein Produkt oder einen Service.

• Strukturierung der wesentlichen Fragen eines Geschäftsmodells und seiner Abhängigkeiten.

• Konzentration auf die Stärken und damit den Wert, der sich mit dem Geschäftsmodell generieren lässt.

http://fa.ltings.de/geschaeftsmodelle-visualisieren/




• Erleichtert die Erfassung gesamter Geschäftsmodelle

• Hilft dabei, stillschweigende Annahmen in eindeutige Informationen zu verwandeln.

• Geschäftsideen werden greifbar und erlauben eine zielführende, klare Diskussion und Anpassungen.

• Die Visualisierung haucht jedem Geschäftsmodell Leben ein und erleichtert die gemeinsame Ideenfindung.

http://fa.ltings.de/geschaeftsmodelle-visualisieren/



Quelle: http://www.businessmodelgeneration.com

http://www.businessmodelgeneration.com/

http://www.businessmodelgeneration.com/













Produktidee (Beispiel): Shirt-Creator

• Firma verkauft bereits T-Shirts, Polo-Shirts, …

• Bisher werden nur feste Varianten davon angeboten

• Idee: Individuell konfigurierbare Varianten (bedruckbar) Personalisierte, qualitativ hochwertige Shirts

• „Konfigurator“ für die Bestellseite



Product Canvas



Produktplanung: Von der Erhebung bis zur Umsetzung

Vision Übergeordnete Ziele

Personas & Szenarien

Epen & User Stories

Product Backlog

Releaseplan (Strategie)

Sprintplan (Taktik)

Refinement



Das Product Canvas

Name Metriken

Zielgruppe:

• Rollen • Personas

„Big Picture“:

• Szenarien • Epen / User Stories • Design-Skizzen • Einschränkungen /

NFAs

Product Details:

• Sprintziele • „Ready“

Stories

Vision / Ziel



Produktvision



Produkt Vision

• Kurz und prägnant

• Emotional und mitreißend

• Sichtbar als Text oder Bild

Vis ion Für wen? Was? Wie? Besser a ls?



Elevator

Pitch Elevator

Pitch



Vision (Beispiel)

Mit dem Shirt-Creator können modebewusste Individualisten mit selbstgestalteten hochwertigen Shirts auffallen.

Kunde: Reseller, Designer, Individualisten

Bedarf: hochwertiges individuelles Kleidungsstück

Hauptvorteil: Kleinserien für Designer

Produkt: Bedrucken von Shirts für alle

über die Bestellplattform für jeden zugänglich machen.



Formulierung einer Vision

Für Kunde

die Beschreibung des Bedarfs

ist das Produktname

eine Produktkategorie, die Hauptvorteil, Grund dieses Produkt zu kaufen; anders als Alternative des Wettbewerbs

kann unser Produkt Beschreibung des Hauptunterschieds.



Vision (Beispiel)

Für Reseller, Designer und Individualisten, die sich nach hochwertigen individuellen Kleidungsstücken sehnen, ist der Shirt-Creator ein Produktkonfigurator, der es modebewussten Individualisten gestattet, mit selbstgestalteten hochwertigen Shirts aufzufallen.

Im Gegensatz zu vergleichbaren Angeboten steht der Shirt Creator Resellern zur Verfügung und gestattet neben der Auswahl vorgefertigter auch die Verwen-dung und Bereitstellung selbst erstellter Motive.



Rollen & Personas



Stakeholder

• Stakeholder sind alle Menschen, die von Entwicklung, Einsatz und Betrieb des Systems betroffen sind (Projektbetroffene)

• Alle mit Einfluss auf die Anforderungen

• Anforderungen/Bedürfnisse aus Nutzersicht Kundennutzen (in den Nutzer hineinversetzen)

• Ein vergessener Stakeholder ist eine vergessene Anforderung

• Stakeholder identifizieren und mit ihren Rollen dokumentieren



Rollen (Beispiele)

Kunden

Designer

Reseller Bestands- kunde

Admin

Neu- kunde Auftrags-

bearbeitung

Händler

Marketing

Support



Personas

• Personas sind am lebenden Menschen orientierte, imaginierte Personen, die unsere Produkte benutzen.

• Sie stehen stellvertretend für Mitglieder realer Nutzergruppen.

• Sie erhalten fiktive, persönliche Eigenschaften.

• Sind wirklickkeitsnah.



Personas

• Personas leisten einen wichtigen Beitrag zum besseren Verständnis der Nutzer-Anforderungen.

• Sie helfen, sich in die Situation der Nutzer zu versetzen.

• Sie fokussieren die Entwicklungsarbeiten auf die Ziele und Bedürfnisse der Nutzer (statt auf die der Projektentscheider, oder auf technische Restriktionen).



Vorlage einer Persona

• Name

• Beruf und Position im Unternehmen

• Erscheinungsbild (Foto bzw. Avatar/Skizze oder Beschreibung)

• Berufserfahrung

• Tägliche Aufgaben (auch außerhalb der Applikation)

• Vorlieben und Hobbys, Abneigungen

• Ziele



Persona (Beispiel)

• 33 Jahre, weiblich

• Alternativ, qualitätsbewusst

• Keine Lust auf „Standardmode“

• Kreativ: Basteln, Einrichten, …

• Beruf: Marketing

• Familie, 1 Kind

Ich wünsche mit die Möglichkeit, eigene Shirts zu gestalten. Ideen dazu entwickle ich selbst und meide Standardmode.

Lisa



Rollen und Personas

• Keine allgemeinen Begriffe wie „Nutzer“ oder „Kunde“.

• Möglichst konkret:

• Konkretes Individum

• Persona

• Rolle oder Jobtitel

• Gruppe oder Abteilung



Szenarien



Szenarien

• Realistisches Beispiel, wie ein Benutzer mit dem geplanten System interagieren wird.

• Einfache Sätze beschreiben einen konkreten Ablauf aus Benutzersicht.

• Inhaltlich richtige Aussagen sind wichtiger als formale Korrektheit.



Szenarien

• Motivation: den Benutzer verstehen.

• Szenarien können iterativ oder zusammen mit den Benutzer erarbeitet werden.

• Die Reflektion am konkreten Beispiel erlaubt es Auftraggebern und Benutzern, Anforderungen in der konkreten Anwendungssituation zu vergegenwärtigen, zu überprüfen und zu ergänzen.

• Gute Grundlage für den Entwurf von User Stories.



Szenarien (Beispiel)

20:00 Uhr Abends, Lisa ist zu Hause und surft im Internet

Lisa hat eine gute Idee für ein individuelles Shirt

Sie ruft den Shop auf und sucht sich mehrere Shirts aus

Ihr „Design“ lädt sie im Shirt-Creator hoch und betrachtet sich ihre Shirt-Modelle

Sie wählt ein Shirt aus und legt es in den Warenkorb, um es zu kaufen

Zwei Tage später wird ihr das Poloshirt nach Hause geliefert

Lisa, individuelles Shirt erstellen



Weitere Darstellungsformen für Szenarien

• Workflow

• Ereignisgesteuerte Prozesskette (EPK)

• Use Case



User Stories



Begrifflichkeiten

• Verschiedene Begriffe werden üblicherweise genutzt, um den relativen Umfang einer Anforderung zu beschreiben

• Die Verwendung ist nicht einheitlich geregelt

• Epic bzw. Epos

• Thema / Feature

• User Story

• Task



Epics / grobe User Stories (Beispiele)

• Lisa möchte individuelle Shirts erstellen können

• Als Designer möchte ich meine Designs anderen Benutzern zur kostenpflichtigen Nutzung bereitstellen können.

• Als Kunde möchte ich Unterstützung bei der Text- bzw. Bildgestaltung der Poloshirts (z.B. Transparenz, Farbgestaltung, …).

• Als Shop-Betreiber möchte ich Auswertungen über die Anwendung haben, damit ich die Kundenwünsche besser erfüllen kann.



User Story: Definition

„Eine User Story beschreibt eine Funktionalität, die entweder für einen User oder Käufer […] von Wert ist.“ Mike Cohn, User Stories applied



Format einer User Story

Als Benutzerrolle

will ich das Ziel

so dass Grund für das Ziel

Wer macht was, warum?



User Stories (Beispiele)

Als Kunde Lisa möchte ich eine Vorschau angezeigt bekommen, damit ich einen Eindruck des Poloshirts erhalte.

Der Käufer möchte hochgeladene Designs speichern können, damit diese später wiederverwendet werden können.



Vorteil von User Stories

Beim Schreiben von User Stories nehmen wir bewusst die Sichtweise des Nutzers bzw. Kunden ein.

Jede User Story zielt darauf ab, den Nutzer bzw. Kunden zufriedener zu machen.



Card, Conversation, Confirmation

User Stories bedeuten, miteinander zu sprechen und zu wissen, wann ein Anforderung umgesetzt ist.

Product Owner

Team

Conversation & Confirmation



Confirmation durch Akzeptanzkriterien

• „Überprüfbare“ Anforderungen

• Gemeinsam erstellt vom Scrum-Team und den Stakeholdern

• Legen fest, ob ein Feature fertig umgesetzt ist

• Bilden die Basis für Akzeptanztests



Akzeptanzkriterien (Beispiele)

Als Kunde möchte ich Bilder hochladen, um diese in meinen Designs zu verwenden. Akzeptanzkriterien: • Der Kunde kann ein Bild auswählen und hochladen. • Die Webshop zeigt das hochgeladene Bild in der Liste verfügbarer

Bilder für Designs an. • Wählt ein Kunde ein anderes Format als JPG und PNG aus, wird

eine Fehlermeldung angezeigt. • Bei Dateien größer als 2 MB wird eine Fehlermeldung angezeigt.



Akzeptanztest

Ein Akzeptanztest ist ein Ablauf, wie die Akzeptanzkriterien überprüft werden kann.

Besteht aus:

• Vorbedingungen

• Ablauf eines Szenarios / Beispiels

• Nachbedingungen bzw. erwartetes Ergebnis



Akzeptanztest (Beispiel)

Als Kunde möchte ich Bilder hochladen, um diese in meinen Designs zu verwenden.

Akzeptanztest: Vorbedingung: Bild test.PNG auf Kundenrechner 1. Der Kunde wählt „Bild hochladen“. 2. Der Browser öffnet den Dateiauswahldialog. 3. Der Kunde wählt Bild test.PNG aus und wählt „Öffnen“ 4. Der Webshop lädt das ausgewählte Bild hoch. Nachbedingung: Der Webshop zeigt das hochgeladene Bild in der Liste verfügbarer Bilder für Designs an.



User Stories in Kürze

• De-facto Standard für agiles Anforderungsmanagement

• Kurze Beschreibung der Anforderung aus Benutzersicht

• Details werden per Konversation ausgearbeitet und in den Akzeptanzkriterien festgehalten



Design-Entwürfe



Design-Entwürfe

• Skizzen

• Wireframes / Mockups

• Ablaufbäume/ -diagramme



Nichtfunktionale Anforderungen



Nicht funktionale Anforderungen (NFA)

• Performance

• Sicherheit

• Wartbarkeit

• Wiederverwendbarkeit

• Verfügbarkeit

• Datenschutz

• …



Definition of „Done“

Sorgt für ein gemeinsames Verständnis, ob eine Arbeit abgeschlossen ist.

Was muss alles getan werden, damit eine Story als „fertig“ angesehen wird?

„Done“ – Es ist nichts mehr zu tun!



Das Product Canvas

Name Metriken

Zielgruppe:

• Rollen • Personas

„Big Picture“:

• Szenarien • Epen / User Stories • Design-Skizzen • Einschränkungen /

NFAs

Product Details:

• Sprintziele • „Ready“

Stories

Vision / Ziel



Anforderungsworkshop mit Product Canvas


79

Weiteres

Beispiel



Weitere Werkzeuge

Welche Themen interessieren Sie am meisten?

1. Specification by Example

2. Refinement & Backlog

3. Zerlegen von User Stories

4. Agiles Schätzen

5. Priorisieren

6. Story Maps

7. Velocity & Release Planung

8. Impact Mapping



Specification by Example



Häufige Probleme

• Anforderungen sind unklar oder mehrdeutig

• Anwender und Entwickler sprechen unterschiedliche

Sprachen

• Domänen-Experten können keine Unit Tests schreiben bzw.

überprüfen

• Die Dokumentation ist bei Änderungen am Produkt nicht

mehr aktuell



Idee

• Konkrete Beispiele beschreiben das Verhalten

• Gemeinsame domänenspezifische Sprache verbessert die

Kommunikation

• Ausführbare Beispiele als „Lebende Dokumentation“



Specification by Example

beschreiben prüfen

Beispiele Tests

Anforderungen

erzeugen

Quelle: Gojko Adzic



Vorteile

• Bessere Zusammenarbeit der verschiedenen Rollen

• Besseres gemeinsames Verständnis der Anforderungen

• Automatisiertes Testen der fachlichen Anforderungen möglich

• Dokumentation passt zum Produkt (Living Documentation)



Quelle: Specification by Example: How Successful Teams Deliver the Right Software, Gojko Adzic



Spezifikation mit Beispielen

1. Use Context: Als ein _ will ich, _ so dass _

2. Allgemeine Regeln des Features

3. Beispiele zu den Regeln

• Präzise, testbar, selbsterklärend

• Geschäftsfunktionalität, in Domänensprache

• „Was“, nicht „Wie“

• Weitere Fälle lassen sich ableiten

• Given - When - Then Sprache



Automatisierte Akzeptanztests












Werkzeuge für die Automatisierung

http://cukes.info/

http://fitnesse.org/

http://robotframework.org/

http://cukes.info/

http://fitnesse.org/

http://robotframework.org/



Selenium Tests



Product Backlog



Product Backlog

• Enthält alle Anforderungen (Backlog Items)

• Geordnet und geschätzt

• Grundlage für die Releaseplanung

• Kommunikationsgrundlage

• Verantwortet durch Product Owner SPRINT

≤ 30 Tage 1 Tag

Product Backlog

Sprint Backlog

Product Increment



Eisberg der Anforderungen

… als nächstes umsetzen

… danach umsetzen

… später umsetzen

Priorität



Refinement



Refinement

„Als Verfeinerung [Refinement] des Product Backlogs wird der Vorgang angesehen, in dem Details zu Einträgen hinzugefügt, Schätzungen erstellt, oder die Reihenfolge der Einträge im Product Backlog bestimmt werden. Die Verfeinerung ist ein kontinuierlicher Prozess, in dem der Product Owner und das Entwicklungsteam gemeinsam die Product Backlog-Einträge detaillieren. „ (Scrum Guide)


• Überprüfen

• Überarbeiten

• Priorisieren

• Analysieren & Klären

• Zerlegen

• Schätzen


Refinement

Product Backlog

Product Backlog Items

Die Verfeinerung des Product Backlog ist ein kontinuierlicher Prozess.

Das Entwicklungsteam wendet dafür bis zu 10% der Sprintzeit auf.


Aktueller Sprint

UserStory

UserStory

UserStory

UserStory

UserStory

UserStory

UserStory

UserStory

UserStory

Nächster Sprint

UserStory

UserStory

Spike

UserStory

UserStory

UserStory

UserStory

UserStory

Nächster nächster Sprint

UserStory

UserStory

UserStory

UserStory. PO clarification

UserStory

UserStory

Sprint 4 -8

UserStory

UserStory

UserStory


Iterative Detailierung



Refinements - Ziele

• Kleine und gut verstandene Backlog Items für die nächsten Sprints („Ready“)

• Verstandene Backlog Items bis zum nächsten Release

• Geschätztes und geordnetes Backlog

• Entwickeln und Anpassen des Release Plans



Zerlegen von User Stories



Gründe für das Zerlegen

• User Stories müssen in einem Sprint fertigzustellen sein.

• Kleinere User Stories lassen sich besser schätzen.

• Kleinere User Stories gestatten eine detailliertere Priorisierung.


Teilaufgaben

Schneiden anhand von Unteraufgaben wie Analyse, Implementierung, Tests etc.

Hinterlässt kein inspizierbares und bewertbares Softwareinkrement.

Schichten

Schneiden anhand von Architektur-schichten wie Datenhaltung, Applika-tionslogik und Nutzerschnittstelle.

Hinterlässt kein inspizierbares und bewertbares Softwareinkrement.

Besser „Durchstich“ mit wenig Funktionalität.


Negativ-Beispiele



Zerlegen von User Stories

1. Workflow-Schritte

2. Variation der Geschäftsregeln

3. Größter Aufwand

4. Komplexität

5. Datenvariation

6. Schnittstellenvariation

7. Nachlagern von NFRs

8. Operationen

9. Spike herausbrechen

Etablierte Muster für das Zerlegen von User Stories

http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/












Praxistipps

• Geeignete Methode zum Zerlegen verwenden

• In wichtigere und weniger wichtige User Stories zerlegen

• Stories nicht in Taskgröße zerlegen

• Ein Spike ist die letzte Möglichkeit

• Stories in einem Sprint umsetzbar

Stories besser schätzbar

Detaillierter zu priorisieren













Agiles Schätzen



Agiles Schätzen

• „Nur“ eine Schätzung!

• Entwicklungsteam schätzt

• Schätzen der Größe

• Abstrakte Einheit: Story Points

• Relatives Schätzen (Referenz)

• Nichtlineare Skala: 1, 2, 3, 5, 8, 13, 20, 40, 100

S L M



Magic Estimation

• Schätzwerte ausgelegt

• Keine Kommunikation!

• Reihum: 1. Neue Story nehmen & auslegen (schätzen) 2. Oder Story umlegen

• Mehrfach umgelegte Stories raus

1 2 3 5 8 13 20



Planning Poker

• Jeder Planning-Pokerkarten

• Diskussion der User Story

• Jeder wählt eine Karte

• Karten gleichzeitig aufdecken

• Unterschiede diskutieren

• Dann ggf. erneut schätzen



Priorisieren



Mögliche Einflüsse auf die Priorisierung

• Aufwand

• Nutzen, Geschäftswert

• Risiko (z.B. Risikomatrix)

• Abhängigkeiten

• Cost of Delay (COD) (Kosten einer späteren Umsetzung)



Priorisierungsmöglichkeiten

• Kano-Modell (siehe nächste Folie)

• Rangliste / Direkter Vergleich

• Sortierung / Ping-Pong-Bälle

• „Bauchgefühl“

MVP (Minimum Viable Product)



Kano-Modell

Erfüllungsgrad

Zufriedenheit

Leistungsfaktoren

Basisfaktoren

Begeisterungsfaktoren

Kreativitätstechniken

Beobachtung



Story Map



Story Map

“Lauffähiges

Gerippe”

“Rückgrat”

R1

R2

R3

Prioritä

t



Story Map (Beispiele)





Releaseplanung



Release Planning

Velocity Ein guter Releaseplan erfordert eine bekannte Velocity.

Backlog Ein guter Releaseplan erfordert ein geordnetes und geschätztes Backlog.


Das Produkt wird zu einem bestimmten Datum released.

“Wie viel des Product Backlog wird an einem bestimmten Datum fertig sein?”

Das Produkt wird released, wenn bestimmte Features fertig sind.

“Wann wird Feature A, B und C fertig sein?”

Basistypen der Release Planung

Feature Target Planning Date Target Planning

147 Agile Requirements Engineering 147



Velocity

Die Velocity beschreibt die Geschwindigkeit, mit der das Entwicklungsteam Product Backlog Items pro Sprint abarbeitet.


0

5

10

15

20

25

30

1 2 3 4 5 6 7 8 9

Sto

ry P

oin

ts

Sprint


Planung mit Velocity

Bester Fall: Top 3 =>

Ø 23

Wahrschein-lichster Fall: Mittlere 3

Ø 19

Schlechtester Fall:

Unterste 3 Ø 14


152

Wann wird Feature A wahrscheinlich

geliefert?


6 Wochen

Product Backlog

Größe: 1

Größe: 20

Größe: 13

Größe: 20

Größe: 3

Größe: 5

Größe: 13

Größe: 8

Größe: 3

Größe: 3

Größe: 13

A


• Mittlere Team Velocity = 32

• Sprint Länge= 2 Wochen


153

Was wird in 8 Wochen alles

geliefert?


Product Backlog

Größe: 13

Größe: 2

Größe: 13

Größe: 1

Größe: 8

Größe: 5

Größe: 13

Größe: 3

Größe: 5

Größe: 2

Größe: 8

Das Alles


• Mittlere Team Velocity = 16

• Sprint Länge= 2 Wochen



Release Burndown

Features Heute

Zeit

Fertigstellung

Velocity: tatsächliche beste durchschnittliche schlechteste



Impact Mapping



Impact Map

• Gemeinsam erstellt von Fachabteilung und Entwicklung

• Mind-Map aus der Diskussion um die vier Fragen Warum? Wer? Wie? Was?

• Visualisierung von Scope und zugrundeliegenden Annahmen Annahmen tranparent machen und in Frage stellen

• Ausrichtung aller Aktivitäten auf die Business Ziele Bessere strategische Planung



Aufbau einer

Impact Map

Warum?

Wer?

Wie? Was?

…

Wie? …

Wer?

Wie? Was?

…

Wie? …

Ziel Person Effekt Feature



Warum?

Wer?

Wie?

Was?

Quelle: http://impactmapping.org

http://impactmapping.org/

http://impactmapping.org/



Impact Map

(Beispiel)

Shirt Verkauf verdoppeln

Kunde

Für Freunde bestellen

Mehrere Adressen

Geschenk-verpackung

Größere Bestellungen

Mengenrabatt

Spontankäufe

Top 10 Designs anpreisen

Rabatt-Aktion

Designer Designs für

Freunde Eigene Designs

teilen

Ziel Person Effekt Feature



Impact Map

• Alles unterstützt das Ziel! (wenn die Annahmen stimmen)

• Mapping von Features auf Ziele

• Scope und Annahmen visualisiert

• Überprüfen der Annahmen möglich

• Konzentrieren auf einzelne Zweige möglich


• Agiles Requirements Engineering

• Business Model Canvas

Werkzeugkasten Product Canvas • Produktvision

• Rollen und Personas

• Szenarien

• User Stories & Epics

• Design-Entwürfe

• Nichtfunktionale Anforderungen

Weitere Werkzeuge • Specification by Example

• Refinement & Product Backlog

• Zerlegen von User Stories

• Agiles Schätzen

• Priorisieren

• Story Map

• Velocity & Release Planung

• Impact Mapping


Zusammenfassung


andrena objects ag

Albert-Nestler-Straße 9

76131 Karlsruhe

Tel. + 49 (0) 721 6105 122

Weitere Standorte:

• Frankfurt

• München

• Stuttgart

www.andrena.de

[email protected]

Experts in agile software engineering 170

Documents

Product Canvas - gpm-ipma.de · Product Canvas 8. Projektmanagement-Tag GPM Region Karlsruhe 3. Juli 2015 Benjamin Seidler, Mustafa Yilmaz