Welche Spalten gibt es auf Ihrem Taskboard?

Derzeit implementieren wir neue Prozesse in unserem Unternehmen im Wesentlichen von Grund auf neu, aber es gibt viele Meinungen darüber, welche Spalten auf dem Taskboard sein sollten. Als Verantwortlicher für diesen Aufwand stecke ich ein bisschen fest, welche Spalten unbedingt erforderlich sind und welche später hinzugefügt werden könnten, wenn sich dies als notwendig erweist. Mein Ziel ist es, die Dinge am Anfang so einfach wie möglich zu halten.

Wir (PM-Team) begannen mit:

| TODO | IN ARBEIT | IN DER PRÜFUNG (QA) | FERTIG |

Aber dann bestanden die technischen Leiter darauf, dass eine CODE REVIEW-Spalte zwischen IN PROGRESS und QA vorhanden sein muss. Abgesehen davon denke ich, dass dieses Argument berechtigt ist, und ich begann mich zu fragen, was wir sonst noch übersehen haben könnten. Ich würde gerne mehr Daten darüber erhalten, was andere PMs als Spalten auf dem Taskboard verwenden.

Ich stimme dafür, diese Frage als nicht zum Thema gehörend zu schließen, da es sich wie geschrieben um eine Umfrage handelt - es gibt keine kanonische Antwort.

Antworten (7)

Das ist eine großartige Frage. Viele Teams beginnen mit etwas wie What you have oder ToDo | Machen | Erledigt. Das mag in Ordnung sein, sagt Ihnen aber nicht viel darüber aus, wie Ihre Arbeit abläuft. Wenn Sie mehr Einblick in Ihren Prozess wünschen, möchten Sie möglicherweise mehr Spalten, aber welche?

Leider gibt es keine "richtige" Antwort. Als PM-Team müssen Sie zunächst verstehen, dass Sie dies nicht standardisieren können. Unterschiedliche Teams arbeiten auf unterschiedliche Weise und müssen unterschiedliche Dinge sehen, also werden unterschiedliche Boards … naja, unterschiedlich sein.

Um ein wirklich nützliches Board zu erhalten, sollten Sie zunächst eine Sitzung zur Prozessabbildung mit Ihrem Team durchführen. Bitten Sie sie, auf einem Whiteboard zu zeichnen, wie sie von „Ich habe eine Idee zu einer Funktion“ zu „Sie können diese Funktion jetzt verwenden“ kommen. Sie können es so visualisieren, wie Sie möchten, aber ich finde, dass grundlegende Flussdiagramme am häufigsten verwendet werden. Fragen Sie sie als Nächstes, auf welche Schritte sie am wertvollsten achten sollten. Dies kann daran liegen, dass es sich um große Schritte handelt oder weil sie riskant sind. Es gibt keine richtige Antwort und sie können ihre Meinung später ändern. Diese werden zu Ihren Spalten. Während die Arbeit nun durch den Prozess fließt, visualisiert das Board diesen Fluss.

In Ihrer Frage fragen Sie, welche Spalten wesentlich sind. Einige Anfangsspalten mit Titeln wie ToDo oder Not Started und Done sind die einzig wesentlichen. Alles andere richtet sich nach dem Ablauf Ihrer Arbeit.

Meiner Erfahrung nach ist die kürzeste Antwort für den Anfang die zwei grundlegenden (to do / done) plus eine für jedes Team .

Ein einzelnes Team, das eine Aufgabe von Anfang bis Ende abdeckt, hätte dann die drei Hauptspalten, dh zu erledigen / in Bearbeitung / erledigt.

Führt in Ihrem Szenario dieselbe Person die Aufgabe und die Codeüberprüfung durch?

  • Ja: Warum also verschiedene Spalten? Nur um den Fortschritt der Aufgabe zu sehen? Sie sollten den Fortschritt anders messen ... vielleicht basierend auf der verbleibenden Arbeit (z. B. Burndown-Diagramm)?
  • Nein: so unterschiedliche Spalten, um sie zu identifizieren, auf diese Weise weiß jedes Team, wann es mehr Arbeit auswählen muss.

Beachten Sie, dass Sie davon absehen sollten, weitere Spalten hinzuzufügen. Irgendwann wird jemand sagen: „Sehen Sie, wir brauchen eine Spalte für die Codeüberprüfung und eine andere für die Codeüberprüfung “. Dasselbe kann beim Testen passieren. Sie können am Ende ein Board mit mehreren Zuständen haben.

Wie Daniel bereits erwähnt hat, hängt alles davon ab, was für Sie und Ihr Team funktioniert.

Daniels Antwort sagt eigentlich alles, aber einige Spaltenüberschriften, die ich gesehen habe, sind:

  • Bewertung des Product Owners
  • Im UAT
  • Bereit für einen erneuten Test
  • verstopft

Nach mehreren Runden mit Experimenten mit verschiedenen Spalten basierend auf unserem Prozess kamen wir zu dem Schluss, dass keine noch so große Bastelei an den spezifischen Spalten die ordnungsgemäße Kommunikation untereinander übertreffen konnte, also reduzierten wir es auf nur „Backlog“, „In Bearbeitung“. " und fertig".

Jetzt haben wir gerade gelernt, als Team so viel zu kommunizieren, dass jeder den genauen Status eines Tickets genau kennt, und wir verfolgen den Fortschritt direkt auf der Karte.

(Auf jeder digitalen Karte befindet sich eine einfache Prozess-Checkliste, die jedoch hauptsächlich dazu dient, entfernte Personen auf dem Laufenden zu halten.)

Unser Produktmanager hat früher mit Whisky gearbeitet, also ist es wie folgt thematisiert:

Vorbereitungen | Fermentieren | Destillieren | Alterung | Abfüllung

Liebe es! Das ist eine tolle Idee!

Einige Ideen aus der Vergangenheit:

  1. Eine Unterspalte für die einzelnen Teams , um die Spalte „In Bearbeitung“ aussagekräftiger zu machen. Z.B:

| TODO | IN ARBEIT | IN DER PRÜFUNG (QA) | FERTIG |
| | ProdOps | Frontend | WERDEN | | |


  1. Abhängig von Ihrer Teamstruktur möchten Sie möglicherweise eine Spalte „In Debugging“ hinzufügen ; In anderen Fällen möchten Sie es möglicherweise wieder auf In Bearbeitung verschieben.

| TODO | IN ARBEIT | IN DER PRÜFUNG (QA) | DEBUGGING | FERTIG |


  1. Eine Spalte „Warten auf Genehmigung“ ; Wenn viele Teile zusammenkommen müssen, kann es nach der QA (erste Runde) sein, aber nicht fertig, bis die zugehörigen Komponenten fertig sind und die QA das gesamte Subsystem genehmigt.

| TODO | IN ARBEIT | IN DER PRÜFUNG (QA) | AUF GENEHMIGUNG WARTEN | FERTIG |

Etwas zu beachten:

Ebenso wichtig und hilfreich wie die Benennung und Verwendung einer Auswahl an Spalten sind die Eingangs- und Ausgangskriterien für jede Spalte. Unser Team hat zum Beispiel Folgendes:


Ein Item kann in das Sprint Backlog aufgenommen werden, wenn...

  1. es ist unabhängig von anderen Workitems (nicht blockiert)
  2. es ist verhandelbar mit dem Produkteigentümer (Geschäftswert wurde bewertet/verstanden)
  3. es ist wertvoll (es wurde basierend auf dem gelieferten Wert priorisiert)
  4. Es wird geschätzt (die Karte wurde auf <= 13 Aufwandspunkte heruntergebrochen)
  5. es ist klein (kann prognostiziert werden, dass es in einen Sprint passt)
  6. es ist testbar (es wurde ein Testansatz vereinbart)

Ein Gegenstand kann die Entwicklung verlassen , wenn er...

  1. Angemessene Unit-Test-Abdeckung?
  2. Geeignete automatisierte Abnahmetestabdeckung?
  3. Angemessene Testabdeckung für die Plattform (Browser/Mobilgerät)?
  4. Eine erfolgreiche Erstellung, Bereitstellung und manuelle Testabdeckung über die Release-Pipeline?
  5. Angemessene Lokalisierung/Globalisierung?
  6. Automatisierungstests bestehen?
  7. Eine vollständig dokumentierte Teststrategie?
  8. Akzeptable Funktionalität basierend auf Akzeptanzkriterien?
  9. Browserkompatibilität mit IE, Firefox, Chrome und Edge?
  10. Peer-Review vom Team?

Ein Artikel kann die Überprüfung verlassen , wenn...

  1. Der Product Owner hat die Funktionalität in QA verwendet und bestätigt, dass die Akzeptanzkriterien erfüllt wurden.

Beachten Sie, dass unser Team nur drei Spalten verwendet, aber die Angabe von Kriterien für jede Spalte hilft wirklich jedem zu verstehen, was passieren muss, damit die Arbeit durch das Board fließen kann, und warum dies geschehen muss. Wenn Sie Scrum verwenden, betrachten Sie dieses Kriterium als Ihre Definition von „Ready“ und „Definition of Done“. Das Obige ist lediglich ein Beispiel und möglicherweise nicht zu 100 % für Sie geeignet. Hoffentlich gibt es Ihnen jedoch einige Ideen und hilft Ihrem Team wirklich zu verstehen, was jede Spalte wirklich symbolisiert, wie auch immer Sie sie definieren. Wenn es nicht funktioniert, können Sie jederzeit neu bewerten, Spalten hinzufügen, Spalten entfernen und ihre Kriterien gemeinsam neu definieren, um sie an die Anforderungen Ihres Teams anzupassen.