Zeitbeschränkung Kanban/Scrum Board

Question

Ich habe die folgende Frage.

Oft in unserem Projekt Probleme bleiben für immer in Arbeit.

Um dies zu beheben, möchten wir einen neuen Arbeitsablauf einführen, bei dem, wenn ein JIRA-Problem zwei Wochen lang inaktiv war, der Status automatisch auf Zurückgestellt gesetzt wird.

Wie kann dies in JIRA implementiert werden? Ich habe die Spaltenbeschränkungen auf der Platine überprüft, aber es gibt keine zeitliche Einschränkung.

Answer 1

Warum steht ein Problem zwei Wochen brach? Liegt es an externen Abhängigkeiten oder ist das Problem in zwei Wochen zu groß?

Ich bin mir nicht sicher über den Jira-Arbeitsfluss und ob Jira ihn in den verschobenen Zustand versetzen kann. Aber Sie können es am Ende des Sprints zurück in den Backlog verschieben.

Aber wenn es passiert, weil das Problem zu groß ist, um in zwei Wochen zu passen, würde ich empfehlen, es in kleinere Aufgaben zu zerlegen, um in Sprint zu passen.

Ich hoffe es hilft.

Answer 2

Ich denke Sie keinen Workflow zu maskieren Ihr Problem in Bezug auf die „Probleme, die für immer im Gang bleiben“ bauen müssen, aber Sie müssen es beheben.

Fixing bedeutet, dass Sie das Team coachen und sie mit verschiedenen Techniken unterstützen müssen, um "nie endende Geschichten" zu vermeiden. Ich würde vorschlagen, zu:

• DOR Implementieren (Definition von Ready) - vermeiden Fragen erstreckt, die noch nicht untersucht werden, gepflegt und nicht klar genug zu holen. In unserem Fall könnte die Geschichte in den Sprint eingefügt werden, nachdem alle externen Abhängigkeiten aussortiert wurden. Verwenden Sie das INVEST Modell, das sagt INDEPENDENT Wie können Sie sich verpflichten, Probleme zu liefern, wo Sie von einem externen Team abhängen?
• Slice große Geschichten - Es gibt viele Techniken, wie große User Stories aufgeteilt werden. Im Allgemeinen ist es eine schlechte Übung, eine Geschichte in den Sprint einzufügen, wenn die Schätzung zeigt, dass sie nicht abgeschlossen werden kann. Idealerweise ist die richtige Größe der Geschichte "dass Sie 2,5 Geschichte für jeden Entwickler im Einzelsprint haben". Dies bedeutet nicht, dass jeder Entwickler an seiner eigenen Geschichte arbeiten sollte und sie nicht zusammenarbeiten können, aber es bedeutet, dass z. 4 Entwickler für einen Sprint 8-10 Geschichten sind ideal. (Einfachere Tests, Zusammenarbeit, bessere Planung, stabilere Geschwindigkeit, etc etc ..)
• WIP (Kanban Grenze in Arbeit) - Putting the 'flow' back in workflow with WIP limits - Atlassian Dies ist etwas, das in Jira leicht konfigurierbar ist.
• Zeigen Sie die 'TAGES IN SPALTE' Anzeige auf Karten - Dies zeigt eine Reihe von Punkten auf jeder Karte (bis zur Breite der Karte oder maximal 32), die Anzahl der Tage, die das Problem war in der Spalte. Dies könnte eine nützliche Information für den Scrum-Master sein, um zu sehen, ob es eine Behinderung gibt, die aussortiert werden sollte
• Verwenden Sie keinen blockierten oder verschobenen Status. Das ist nur mein persönlicher Rat.Status wie blockiert/verschoben können eine Gewohnheit erzeugen, dass die Probleme wirklich nur verschoben werden, anstatt das Hindernis und den Blocker zu entfernen. Es ist immer einfacher, etwas als blockiert zu markieren, als das Hindernis zu entfernen. Es ist Ihre Verantwortung, die Hindernisse zu beseitigen und die Verschwendung zu beseitigen.
• Backlog Grooming - Pflegen Sie den Rückstand regelmäßig und wenn Sie Probleme mit den externen Abhängigkeiten haben, kennzeichnen Sie sie im Voraus. Suche nach externen Abhängigkeiten nach Zweck und identifiziere sie so schnell wie möglich. Dies wird der SM/PO hoffentlich genug Zeit geben, sich mit ihnen zu befassen, bevor das Problem in den Sprint aufgenommen und vom Entwicklerteam aufgegriffen wird.