Das Problem Statement ist eine Technik ein Problem strukturiert zu beschreiben und so mehr Klarheit für sich selbst oder eine andere Person über ein vorliegendes Problem zu erlangen. Es ist ein super Werkzeug, was in jede Werkzeugkiste eines Scrum Masters gehört.
Das Problem Statement in der Übersicht
Das Problem Statement ist eine formale Beschreibung eines Problems anhand von fünf Feldern. Es kann Varianten und weitere Derivate geben und ich empfehle dir auch dieses nur als Impuls oder Rahmenbedingung zu nutzen.
Die einzelnen Felder des Problem Statements
Du kannst dir ganz am Ende des Artikels eine Vorlage herunterladen und es ausprobieren. Ich beziehe mich auch diese Vorlage. Ich gehe mit dir nun Feld für Feld der Vorlage anhand eines Beispiel von einem Scrum Master durch.
Um wen geht es? Die Rolle
Wir blicken auf das Problem durch den Anwender. Das ist ähnlich zur User Story. Kennen wir den Menschen, kennen wir die Rolle in der der Mensch aktiv ist, können wir in die Diskussion mit dieser gehen und auch die Perspektive besser verstehen.
Beispiel: Nehmen wir an, du bist Scrum Master und das Problem, welches du beschreibst möchtest du aus dieser Sicht sehen. Dann trägst du in das erste Feld "Scrum Master".
Feld | Inhalt |
|---|---|
ich als | Scrum Master |
führe | |
aber | |
weil | |
ich fühle mich dabei |
Was macht die Rolle? Die aktuelle Situation und Realität
In diesem Bereich kannst du beschreiben, was die Person macht, wie der Alltag ist oder um welche Situation es hier genau geht. In diesem Feld geht es sehr oft um den Kontext. Wie groß oder wie konkret ist dieser? Davon hängt später auch ab, wie gut du direkt mit dem Problem schon arbeiten kannst.
Beispiel: Unser Scrum Master hat nun ein Problem innerhalb einer Retrospektive. Also beschreiben wir diesen Rahmen oder diese Situation so gut, wie es nur geht. Haben wir dafür eine gute Formulierung, halten wir sie im Feld wie folgt fest.
Feld | Inhalt |
|---|---|
ich als | Scrum Master |
führe | regelmäßig mit meinem Team eine Retrospektive durch |
aber | |
weil | |
ich fühle mich dabei |
Achtung Stolperfalle: Wenn du diesen Kontext zu groß machst, wird es dir später schwer fallen, konkret damit zu arbeiten. Als Tipps kannst du immer versuchen das Problem auf die minimale Konsistenz zu reduzieren. Sollte das mal gar nicht gehen, schau ob eine Teilbetrachtung sinnvoll sein kann.
Das „aber“ - was ist aufgetreten, was ist passiert?
Wenn wir keine besonderen Situationen hätten und alles wie geplant laufen würde, dann gebe es das Feld auch nicht. Hier geht es darum zu beschreiben, was genau auftritt. Was ist ungewöhnlich, was weicht ab, was erwartest du nicht. Und das hältst du hier fest.
Beispiel: Unser Scrum Master, der nun regelmäßig Retrospektiven durchführt, findet nun einen Punkt der - in diesem Beispiel - immer auftritt. Und zwar fehlt ihm das systematische
Feld | Inhalt |
|---|---|
ich als ... | Scrum Master |
führe | regelmäßig mit meinem Team eine Retrospektive durch |
aber | wir als Team schaffen es nicht, uns systematisch auf Verbesserungen zu einigen, die wir auch umsetzen |
weil | |
ich fühle mich dabei |
Grundursache - eine erste ANalyse des Warum’s mit dem Weil
Wir versuchen den Grund zu ermitteln. Das ist spannend und gleichermaßen wirkungsvoll die das "um" bei der User Story. Wenn wir das Warum kennen, regt sich meistens schon mehr im Denken.
Beispiel: Nehmen wir an, du bist Scrum Master und das Problem, welches du beschreibst möchtest du aus dieser Sicht sehen. Dann trägst du in das erste Feld "Scrum Master".
Feld | Inhalt |
|---|---|
Ich als | Scrum Master |
führe | regelmäßig mit meinem Team eine Retrospektive durch |
aber | wir als Team schaffen es nicht, uns systematisch auf Verbesserungen zu einigen, die wir auch umsetzen |
weil | wir immer hitzige Debatten über das Für und Wider führen |
ich fühle mich dabei |
Wie fühlt sich die Person? Emotionen
Eine interessante Perspektive kann es sein, sich auf die Gefühle einzulassen. Was empfindet die andere Person beim Erleben des Problems. Das lässt noch mal Rückschlüsse zu und auch eine Reflexion des eigenen Eindrucks.
Beispiel: Nehmen wir an, du bist Scrum Master und das Problem, welches du beschreibst möchtest du aus dieser Sicht sehen. Dann trägst du in das erste Feld "Scrum Master".
Feld | Inhalt |
|---|---|
Ich als | Scrum Master |
führe | regelmäßig mit meinem Team eine Retrospektive durch |
aber | wir als Team schaffen es nicht, uns systematisch auf Verbesserungen zu einigen, die wir auch umsetzen |
weil | wir immer hitzige Debatten über das Für und Wider führen |
ich fühle mich dabei | sehr niedergeschlagen und hilflos |
Und wie hilft das Problem Statement nun?
Wenn du das obige Beispiel nicht so konkret gefasst hättest, dann wären vielleicht andere Sichtweisen auf das Problem aufgetaucht. Dann wäre meistens nicht klar, wo genau das Problem auftritt.
Sich durch eine Retrospektive niedergeschlagen zu fühlen ist eines, es zu benennen, dass durch die hitzigen Debatten entsteht, ist schon eine wertvolle Erkenntnis.
Dadurch, dass du nun das Problem so genau beschrieben hast, sind Lösungen deutlich näher zu bestimmen. Nicht umsonst sagt man gerne: Wenn du das Problem beschreibst, hast du 50% der Lösung schon erarbeitet".
Problem Statement und Lösungen finden
Das Problem Statement selbst schenkt dir noch keine Lösung. Es ermöglicht dir aber konkrete Ideen oder Maßnahmen zu finden. Dafür kannst du dann weitere Techniken nutzen. So eignet sich oft ein Fischgrätendiagramm oder ähnliches sehr gut.
Vorlage
Ich habe dir hier eine Vorlage bereitgestellt, die sich sehr an dem Beispiel in diesem Artikel orientiert:
Feld | Inhalt |
|---|---|
ich als | |
führe | |
aber | |
weil | |
ich fühle mich dabei |
Lade dir gerne diese Vorlage kostenlos aus meinem Google Account herunter: Die Problem Statement Vorlage!
