Scrum-board / Task Board und Farbcodierung [geschlossen]

Question

Was würden Sie so weit wie eine gute Farbcodierung für die Verwendung auf einem Storyboard empfehlen?

Ist das ein gutes Muster aus Ihrer Erfahrung?
http://maxheapsize.com/static/ScrumBoardCheatSheet.pdf
Was ist die Standard-Farbcodierung?

Answer 1

Ich schlage vor, weiß für die normalen Backlog Items, das heißt solche mit Mehrwert, und rot für Fehlerbehebung. Dies macht Fehler auffallen und hilft das Team zu verbessern.

Starten Sie einfach - so einfach, wie Sie es wagen, es zu machen - und Innovationen ermöglichen, wie durch das Scrum Team während Sprint Retrospektiven vorgeschlagen. Nur eine Innovation zu einer Zeit; versuchen Sie es lange genug, um zu sehen, wie gut es wirklich funktioniert; fallen sie, wenn sie nicht wirklich notwendig sind.

Answer 2

Sie nicht etwas Besonderes machen. Verwenden Sie gesunden Menschenverstand. Ich habe keine Farbcodes verwendet, weil ich sie nicht denken, viel helfen - sie selbst es schwierig für andere Akteure mehr machen den Taskboard zu verstehen. Dies führt zu weniger Transparenz. Ansonsten bin ich mit Morendil.

Answer 3

Für Backlog Items ich großen Post-its (4x4): User Stories (Blau / Grün), Defekte (rot), Ausnahmen (Gelb), Investigational (lila).

Für Aufgaben verwenden wir regelmäßige Größe Post-its (3x3): Dev Aufgaben (Gelb: Denn sie sind am einfachsten zu bekommen, und die meisten der Vorstand wird Dev Aufgaben sein), QA (Grün), Entwurf (blau), Bugs (Pink), ScrumMaster / Impediments (orange).

Wir beginnen den Sprint mit blass / Pastell Post-its, und alles, was letzten Sprint-Planung hinzugefügt wird, wird auf neon der gleichen Farbe getan. So blass gelb gegen neongelb, und so weiter. Auf diese Weise können wir sehen, was hinzugefügt wurde zu markieren, um wirklich, wenn wir nicht einen guten Abbau zu tun haben oder wenn es Tonnen von Unbekannten Start des Sprints.

Hope, das hilft.

Answer 4

Ich habe das Spektrum gesehen, wenn es um Kartenfarben und Pannen kommt. Einige Teams nutzen eine Karte Farbe, weil eine Aufgabe, eine Aufgabe ist, ist eine Aufgabe, unabhängig von der Arbeit beteiligt. Andere Teams haben Farben für jede Art von Aufgabe, die mir irgendwie gefallen, da es eine schöne Aussicht auf die Art der Arbeit gab verlassen, ohne jede Karte lesen zu müssen.

Geschichte Karten: blau Technische Schulden: grün Bugs: gelb Analyse: rot QA (nicht Geschichte QA, sondern Aufgaben, die QA außerhalb der normalen QA tat): weiß

Dies trug dazu bei, wenn wir ein großes Team mit einer Reihe von Nicht-Entwickler rund um den Tisch sitzen hatten.

Answer 5

Ich bin damit einverstanden, die mehr Farben, die Sie die mehr Sie sind blind . Ich ziehe es Mängel, Geschichten und Epen highlite. Im Sprint Backlog gibt es nur zwei Farben - Orange für Defekte und Gelb für Geschichten. ScrumDesk zum Beispiel ermöglicht es Farbe auf eine Karte in Geschichte Vorlage zuweisen, die Backlog richtig farbig zu halten hilfreich ist.

Die Farben sind sehr brauchbar, wenn Rückstau mehr Produkte (Programmbestand) beschreibt. In diesem Fall Farben könnten Epen nach Produkt highligt.

Answer 6

Es sieht nach meinem Geschmack überlastet. Als ich Scrum vor einigen Jahren gelernt, die einzigen Farbcodes waren weiß und rot. Die roten Geschichten waren Integration Geschichten. Wenn Sie zu viele von denen im Product Backlog bekommen nahe beieinander - sind Sie in Schwierigkeiten. Wie dem auch sei, gab ich Low-Tech-Brett auf einem ersten Sprint mit, denn ich Remote-Teammitglieder hatte, und so nahmen wir einige elektronischer Form -. Excel, TWiki, VersionOne, Rally