Wie plant man Back- und Front-End-Entwickler basierend auf Story Points?

Wir sind es gewohnt, mehrere Unteraufgaben für jede User Story zu erstellen und jede Unteraufgabe mit einer Schätzung in Stunden und Beauftragten ( Back- oder Front-End ) zu versehen.

Mit folgendem Ergebnis:

  • Gesamte geschätzte benötigte Zeit in Stunden für die User Story , aufgeteilt auf Back- und Front-End
  • Die Verfügbarkeit von Back- und Frontend- Entwicklern kann berücksichtigt werden, wenn User Stories in Sprints platziert werden
  • Entwickler werden in Harvest Forecast basierend auf ihrer Verfügbarkeit und ihrer Back- oder Front-End- Rolle entsprechend eingeplant

Trotzdem können wir keine genaue geschätzte Zeit angeben. Deshalb wollen wir unser Projektmanagement anpassen:

Wenn wir all dies anwenden, werden wir höchstwahrscheinlich eine genauere Gesamtschätzung für einen Sprint erreichen und basierend auf der Geschwindigkeit einen machbaren Arbeitsaufwand in einem Sprint planen.

Wir haben nur ein Problem. Wenn wir keine Teilaufgaben mehr für die Schätzung verwenden, wissen wir auch nicht, wie viele Stunden ein Back- oder Frontend- Entwickler in Harvest Forecast eingeplant werden muss .

Daher die Frage: Wie plant man Back- und Front-End- Entwickler basierend auf Story Points?

Verwandt:

Planen Sie sie für jeweils 40 Stunden pro Woche ein. Schätzen Sie Projekte in Wochen mal Personen, nicht in Aufgabenaufschlüsselungen. Kurz gesagt, seien Sie weniger granular, um die Gesamtgenauigkeit zu verbessern.
@ToddA.Jacobs danke! Aber was, wenn sich herausstellt, dass es sich zu 70 % um Back- und zu 30 % um Front-End handelt?
Wenn Sie die Vorteile der agilen Schätzung nutzen möchten, fallen Sie nicht auf den Trugschluss der 100-prozentigen Auslastung herein und führen Sie keine individuelle Schätzung durch. Schätzen Sie die Arbeit für das Team als Ganzes.

Antworten (2)

Wenn ich richtig interpretiert habe, lautet Ihre Frage, wie Sie Story Point-Schätzungen für User Stories in Zeitschätzungen für jeden einzelnen Entwickler umwandeln können.

Meine Antwort?

Nicht.

Der einzige mögliche Grund, warum ich mir vorstellen kann, warum Sie individuelle Schätzungen benötigen , sind einzelne KPIs (Key Performance Indicators). Die meiner Erfahrung nach selbst schädlich sind.

Stattdessen sollten Sie für das Team kalkulieren . Behandeln Sie das Team als geschlossenes Ganzes. Anstatt Entwickler F 1 Tag und Entwickler B 2 Tage zu beanspruchen, nimmt die Story Team 2 Story Points. (Die Sie dann in Zeitschätzungen für das Team umwandeln können, wie ich glaube, wurde hier schon einmal beantwortet).

Aus deinem Kommentar:

Aber was, wenn sich herausstellt, dass es sich zu 70 % um Back- und zu 30 % um Front-End handelt?

Das riecht für mich nach dem 100% Utilization Fallacy . Es stellt sich also heraus, dass 70 % Back-End und 30 % Front-End benötigt werden … na und? Das bedeutet, dass die Front-End-Entwickler in diesem Sprint ihre Pufferzeit effektiver nutzen können. Vielleicht können sie sich mit den Back-End-Entwicklern zusammenschließen, um T-förmig zu werden .

Danke, sehr aufschlussreich! Der Grund ist, Entwickler so effizient wie möglich über mehrere Projekte hinweg einzusetzen (bei 70 % Back- und 30 % Frontend) und dem Kunden so ein gutes Preis-Leistungs-Verhältnis zu bieten, könnte ich mich irren?
@BartvanKleef Sehen Sie sich den Trugschluss der 100% igen Auslastung an. Sie sollten den Durchsatz von Aufgaben optimieren, nicht die Zeit von Entwicklern.
@BartvanKleef Ich warne davor, dieselbe Person auch auf mehrere Projekte zu verteilen. Diese Art von Kontextwechsel ist mit enormen Kosten verbunden und endet unweigerlich damit, dass zwei Projekte um 70 % der Zeit derselben Person kämpfen. Das führt zu einem miserablen Arbeitsplatz und Burnout.
@BartvanKleef: Was würden Sie tun, wenn die meisten Projekte für den nächsten Monat zu 70 % zurück und zu 30 % vorne sind? Die Hälfte Ihrer Front-End-Entwickler unbezahlten Urlaub schicken?
@BartvanIngenSchenau gute Frage! Wir haben einige Mitarbeiter auf Abruf (0 Stunden). Oder wir platzieren sie in unseren eigenen Nebenprojekten anstelle von Kunden. Nie unbezahlter Urlaub.
@RubberDuck, genau aus diesem Grund verwenden wir Harvest Forecast. Planen Sie Entwickler für einen Sprint basierend auf ihrer Verfügbarkeit an aufeinanderfolgenden Tagen ein. In dem angegebenen Beispiel werden sowohl Back- als auch Front-End-Entwickler für einen zweiten Sprint (und damit ein weiteres Projekt) später in derselben Woche eingeplant (weil es zusätzliche Back- oder Front-End-Arbeiten gibt). Wie sonst geben wir dem Kunden ein gutes Preis-Leistungs-Verhältnis?
@Sarov, da hast du einen guten Punkt!
@BartvanKleef Wenn Sie Entwickler basierend auf ihrer Verfügbarkeit und der Arbeit für einen Sprint einplanen, tun Sie nichts, was nicht einmal mit Scrum zu tun hat. Wenn Sie es also einen Sprint nennen, kann dies die Leute nur verwirren.

Ein Ansatz, den ich erfolgreich gesehen habe, ist wie folgt.

Das Team schätzt jedes Backlog-Element in Story Points. Das gesamte Team schätzt und einigt sich auf die Zahl der Story Points basierend auf der relativen Größe.

Die in früheren Sprints gemachten Story Points werden verwendet, um die Geschwindigkeit des Teams zu berechnen. Dies bietet einen Anhaltspunkt für die Kapazität zukünftiger Sprints.

Im Planungsmeeting zieht das Team Storys aus dem Product Backlog, bis sie ihre Kapazität erreicht haben. Wenn die Geschwindigkeit des Teams beispielsweise 30 Story Points beträgt, würden sie dem Sprint Backlog Storys hinzufügen, bis sie fast 30 Story Points erreichen.

Als nächstes schaut sich das Team die Story mit der höchsten Priorität im Sprint Backlog an und schlüsselt sie in technische Aufgaben auf. Sie schätzen die fachlichen Aufgaben stundenweise ein und vermerken, ob sie eine Spezialisierung benötigen (z. B. Frontend-Entwickler oder Backend-Entwickler).

Das Team verwendet dann denselben Ansatz für jede der verbleibenden Storys im Sprint-Backlog. Dabei verfolgt der Scrum Master die Stunden für jede Spezialisierung. Wenn sie bemerken, dass eine Spezialisierung überlastet wird, teilen sie dies dem Team mit. An diesem Punkt kann das Team entweder:

  • Entfernen Sie alle Storys aus dem Sprint Backlog, die noch nicht in technische Aufgaben heruntergebrochen wurden
  • Sehen Sie sich den oberen Teil des Produkt-Backlogs an und prüfen Sie, ob es Geschichten gibt, die sie in den Sprint einbringen können, der eine bessere Arbeitsverteilung für die verschiedenen Spezialisierungen schafft

Dadurch wird sichergestellt, dass keine Spezialisierung im Sprint überlastet wird.

Es ist erwähnenswert, dass ein besserer langfristiger Ansatz darin besteht, sicherzustellen, dass die Teammitglieder über T-förmige Fähigkeiten verfügen . Wenn Teammitglieder sowohl Front-End- als auch Back-End-Entwicklungsarbeit leisten können, dann können sie:

  • Seien Sie viel flexibler mit den Arten von Geschichten, die sie in Sprints einbringen
  • Machen Sie sich weniger Sorgen darüber, dass Teammitglieder unter- oder überlastet sind
  • Verbringen Sie weniger Zeit mit Schätzungen
Danke für das Teilen! Dies scheint mir der richtige Ansatz, um Story Points in Schätzungen für User Stories für Back- und Frontend umzuwandeln, wenn Sie möchten.
Wie plant man Back- und Front-End-Entwickler basierend auf Story Points?
AntwortenHierDatenschutz-Bestimmungen1y, 0v