Artefakte

Lightweight-Business-Case (LBC)

Der Light-weight-Business-Case ist dem SAFe-Framework entlehnt und beschreibt ein Feature auf leichtgewichtige Weise. Dazu gehören Ergebnisse einer ersten Analyse, wie Aufwand und Investitionen, sowie Vorteile und Nutzen, um die Priorität einschätzen zu können. Beispiel für ein LBC-Backlog-Element Description: What (is the problem?) What is the context? Stakeholders, Users, Markets: Who needs/benefits? Acceptance Criteria: inScope, outOfScope…

Machbarkeit

Eine der wichtigsten K-Gaps in der physischen Produktentwicklung ist die physische „Machbarkeit“.  Diese enthält Fragen wie Gibt es geeignete Wirkprinzipien und welche sind das? -> (Optionen) Gibt es geeignete Materialien?

NABC

NABC ist eine Methode für die Entwicklung, Bewertung und Präsentation von Ideen, entwickelt vom Standford Research Institute (SRI). Der vorgestellt NABC-Canvas ist eine Vorlage, das NABC-Vorgehen durchzuführen und zu verschriftlichen. Need, Approach, Benefit, Competition = Bedürfnis, Ansatz, Nutzen, Wettbewerb NABC Need beschreibt die Bedürfnisse bzw. Probleme der Kunden, Stakeholder oder Benutzer. Mit den Needs zu…

Nutzbares Wissen & dokumentierte Entscheidungen

Nutzbares und dokumentiertes Wissen ist die Grundlage jeglicher Systementwicklung. Nutzbares Wissen ermöglicht es, bewusste Design-Entscheidungen zu treffen. Nutzbares Wissen stellt zudem die erste Stufe der Wiederverwendung (siehe Prinzipien) dar. Auf einer höheren Ebene stellen diese auch das Wissen über die Möglichkeiten und Einschränkungen (Design-Limits & Trade-offs) von integrierten Systemlösungen dar. Um dies zu erlangen, sind…

Organisations-DoD

Die Teams aller Cluster der Organisation, die Cluster-System-Engineer-Gruppe, die Cluster-Product-Owner-Gruppe und die Stakeholder müssen verstehen was es bedeutet, wenn ein Backlog-Eintrag oder ein Ergebnis als „Done“ bezeichnet wird. Obwohl sich die Cluster-DoDs erheblich von Cluster zu Cluster unterscheiden können, gibt es nur eine DoD auf Portfolio-Ebene für die gesamte Organisation. Alle müssen ein gemeinsames Verständnis…

Organisations-Improvement-Backlog

Das Improvement-Backlog beschreibt den Vorrat an Verbesserungen und wird von der entsprechenden Einheit, selbst-organisiert, in die Arbeitsplanung integriert. Eine Regel, die beschreibt, wie viel Arbeitsaufwand für Verbesserungen investiert wird (z.B. 10-20%), hilft die Planbarkeit und Vorhersagbarkeit von anderen Backlog-Einträgen hoch zu halten. Das Improvement-Backlog ist das Planungs- und Strukturierungswerkzeug des Scrum-Masters. Improvement-Backlogs gibt es auf…

Organisations-Mission

Inhalt einer Mission Die Mission deckt die Verantwortungsbereiche (das Was) und die Kultur und Verhaltensstandards (das Wie) ab. Die Mission klärt folgende Punkte: Wie sieht unser Selbstverständnis aus. Was ist der Sinn (Purpose) des Teams. Wie verortet sich das Team innerhalb des Clusters und der Organisation. Welche Verantwortung trägt das Team und sein PO (Produkte,…

Portfolio-Backlog-Item (PFBI)

Portfolio-Backlog-Items (PFBI) sind die einzelnen Elemente (Backlog-Items) des Portfolio-Backlogs und beschreiben Arbeiten für die ganze Organisation. Von der Größe her ist ein PFB zu Beginn nicht beschränkt. Es muss aber vor der Einplanung im Portfolio-Planning, d.h. vor dem Ziehen in das Portfolio-Cycle-Backlog, in mehrere, in einem Portfolio-Cycle leistbare Einzelelemente, aufgeteilt werden. Dies geschieht normalerweise in…

Portfolio-Backlog, Portfolio-Cycle-Backlog und Portfolio-Kanban

Die oberste Ebene der Backlogs des P4-Frameworks, die Portfolio- und Organisationsebene, beschreibt alle zu entwickelden Applikationen und Marktvarianten der Systeme und Produkte der gesamten Organisation. Jede dieser Varianten wird durch einen Satz von System-Anforderungen (Feature Set) beschrieben. Auf diese Weise sind die zu entwickelnden Applikationen, Systeme und Produkte (= Portfolio-Backlog-Elemente) sowohl bezüglich des Nutzens, als…

Produkte, Applikationen und Marktvarianten

Das Portfolio-Backlog auf Organisationsebene, der oberste Ebene der Backlogs, enthält Systeme, Produkte und technische Produktvarianten, sowie Produktvarianten für spezielle Märkte. Jede dieser Produktvarianten wird durch einen Satz von System-Anforderungen (Feature Set) beschrieben. Auf diese Weise sind die Produktvarianten sowohl bezüglich des Nutzens, als auch bezüglich des zu investierenden Aufwands gegeneinander abschätzbar. Hierfür wird im P4-Framework…