Kanban und Feature-Größe

Sie können die spezifischen Größenpunkte für Geschichten loswerden und auf ein einfacheres Niveau von S, M, L (T-Shirt-Größen) zurückgreifen. Dann können Sie den Durchsatz und die Zykluszeit (Zeit, die benötigt wird, um ein Feature fertigzustellen) für jede Größe messen, sodass Sie im Laufe der Zeit feststellen würden, dass ein „S“ im Durchschnitt X Tage und ein „M“ X Tage dauert und so weiter.

Sie werden auch etwas über die Größenvariabilität innerhalb verschiedener Feature-Cluster lernen, z. B. ist die Größenvariabilität großer Features wahrscheinlich größer als die kleiner Features.

Beachten Sie, dass die Verwendung der T-Shirt-Größe anstelle der Story-Point-Schätzung weniger Zeit in Anspruch nehmen sollte, da es sich um eine grobkörnigere Methode handelt. Basierend auf historischen Daten (Durchsatz und Zykluszeit und Variabilität) sollte die Qualität Ihrer Schätzungen jedoch verbessert werden.

Ich würde Ihre WIP-Limits in den Spalten jedoch nicht ändern. Das Ziel ist es, Gegenstände durchzutreiben, und nicht, dem Team zu erlauben, mehr zu übernehmen, nur weil sie alle "S" sind. Dann sind Sie gerade wieder beim Kontextwechsel. Beachten Sie jedoch, dass besonders große Features den Durchfluss und die Zykluszeit negativ beeinflussen würden.

Vielleicht lernen Sie daraus, wie Sie Geschichten, auf die Sie kommen, besser in Stücke zerlegen können, die alle "S" oder "M" sind, und entscheiden, dass die "L"s zu viel Variabilität in ihrem Durchsatz haben.

Holen Sie sich zunächst einige Daten, um die Entscheidung zu treffen.

Ich würde mit der Dimensionierung von Storys fortfahren, wie Sie es im Moment tun, aber anfangen, auf Pull-Basis zu arbeiten, anstatt sich für jeden Sprint auf eine bestimmte Anzahl von Punkten festzulegen.

Überwachen Sie für einen oder zwei Monate sowohl die pro Woche abgeschlossenen Punkte als auch die pro Woche abgeschlossenen Stories. Hoffentlich werden Sie feststellen, dass das Verhältnis von Geschichten zu Punkten pro Woche ziemlich konstant ist – das sollte Ihnen das Selbstvertrauen geben, mit der Größenbestimmung aufzuhören und nur die Anzahl der Geschichten zu verfolgen.

Ein weiteres Datenelement, das Sie sich ansehen sollten, ist die Verteilung der Story-Größe. Probieren Sie einige frühere Sprints aus. Wenn Sie feststellen, dass die meisten Ihrer Geschichten in den Bereich x bis y fallen, aber gelegentlich eine viel größere (oder kleinere) Geschichte hereinkommt, sollten Sie Ansätze wie Schwimmbahnen oder verschiedenfarbige Karten für große (oder kleine) Geschichten in Betracht ziehen.

Das Kanban-Buch von David Anderson enthält einige gute praktische Beispiele in dieser Richtung.

Aus meiner Erfahrung sollte man bei der bisherigen Arbeitsweise bleiben - ich meine bei Story Points. Zu viele Änderungen zu Beginn des Übergangs können Ihren Übergang zu Kanban/Scrumban erschweren. Ich würde empfehlen, ein Kanban-Tool zu finden, das Story Points unterstützt.

Es ist wahrscheinlich eine gute Idee, zunächst nicht viele Änderungen vorzunehmen.

Wenn Sie mit Funktion eine große Arbeit meinen, die in kleinere Aufgaben aufgeteilt wird, wurde mir empfohlen, die Anzahl der Aufgaben zu schätzen, in die diese Funktion aufgeteilt werden würde. Sobald Sie die Anzahl der Aufgaben geschätzt haben, die für eine Funktion erforderlich sind, können Sie Ihre Vorlaufzeit-Metrik verwenden, um abzuschätzen, wie lange es dauern wird, diese Funktion auszuführen. Ich mag diesen Ansatz, weil Sie Ihre 3-4-monatige Schätzung vornehmen können, ohne die ganze Arbeit zum Aufschlüsseln der Funktion auf sich nehmen zu müssen.

In Bezug auf Aufgaben unterschiedlicher Größe denke ich, dass es Ihnen gut gehen würde, wenn Ihre Aufgaben relativ nah genug an Größe wären, damit das Gesetz der Durchschnittswerte Ihnen eine vernünftige Vorlaufzeit-Metrik geben würde. Ich würde aus verschiedenen Gründen nicht empfehlen, große Arbeitspakete in die Warteschlange zu stellen. Verwenden Sie stattdessen die Spidr-Techniken , um eine Geschichte aufzuschlüsseln.