Diese Kurzgeschichte widmet sich der Frage, wie man nicht in die Falle der imaginären Kontrolle über den Prozess der Aufgabenschätzung für den bevorstehenden Sprint geraten kann. Ich muss sofort sagen, dass die unten dargestellten Daten nur Richtwerte sind und Kommentare zur Nichtverwendung von Fibonacci-Zahlen zum Zwecke der Schätzung überflüssig sind.
Unser Team bestand aus einem Analysten, Tester, Designer und zwei Entwicklern. Aus Gründen der Klarheit lassen wir jedoch nur die Entwickler.
Wir starten einen neuen Sprint und fahren reibungslos mit der Bewertung der User Stories fort. Nichts Neues. Mach weiter ...
Die Planung ist abgeschlossen und die Ergebnisse sind oben zu sehen. Sie nahmen 3 User Stories mit einem Wert von 16, 20 bzw. 37 Story Points auf. Insgesamt - 73.
Wie jedes selbstbewusste Entwicklungsteam, das alle Freuden der Arbeit an Scrum liebt, fügen wir diese Bewertungen Jira hinzu. Gleichzeitig führen wir nur allgemeine (oder durchschnittliche - noch schlimmer!) Schätzungen für jede Geschichte ein.
Zwei Wochen Arbeit, ohne die Hände von der Tastatur zu nehmen und ohne vom Bürostuhl aufzustehen, der seit Jahren so beliebt ist, können Sie über die neu erstellte Funktionalität nachdenken.
Aber was ist los? Der Sprint ist vorbei und wir sehen, dass die Front alles wie geplant gemacht hat und keine Zeit mehr hatte, mehr Tastenanschläge auszuführen. Die Rückseite ging über den Sprint hinaus und erledigte mehr Aufgaben als geplant.
Und dann erscheinen Scrum und XP vom Trenches PM, der gerade mit dem Lesen fertig ist und sagt: „Alles ist klar !!! Wir müssen mehr Baupunkte für den nächsten Sprint mitnehmen und dann wird alles in Ordnung sein und kein Rückhalt wird mehr vor mir davonlaufen und sie mitnehmen !! "
Wir planen einen neuen Sprint ....
Großartig! Hat 10 Storipoints mehr gebraucht !!! Jetzt haben wir alles sicher berechnet !!
Weitere 2 Wochen vergehen schnell und es ist Zeit, Bilanz zu ziehen.
Aber zu jedermanns Bedauern endete der Sprint ganz anders, als wir es gerne hätten.
Aus irgendeinem Grund zog sich der Rücken wieder nach vorne und die Front hatte keine Zeit, das zu tun, was sie geplant hatten (die Möglichkeit, dass die Front nur ein unerfahrener Juni ist, und wir werden den unberührbaren Senor des Rückens senken und uns vorstellen, dass das Ganze nur in der falschen Planung ist).
Ein weiterer Sprint war ein Fehlschlag !!! Aber warum haben wir einiges mehr Storypots genommen und das nur zu guten Zwecken - um die nötige Menge Arbeit für die Serverseite zu geben ??!?
Wie kann das sein? Die Antwort dreht sich alles um das Bewertungssystem selbst. Zurück zu unseren Sprints.
Was sehen wir? Es stellt sich heraus, dass wir beim neuen Sprint mehr Storpoints zum Laden des Rückens genommen haben, sondern nur die Front.
Nachdem wir dies verstanden haben, ist der erste Gedanke in PMs verrücktem Kopf herauszufinden, wie viele Story-Punkte die Front auf sich genommen hat und wie viel Rückendeckung. Ein Blick auf die Gesamtnote in Jira ist jedoch einfach nicht möglich, da Sie nur die Gesamtnote (gut oder durchschnittlich) für jede Geschichte herausfinden und sich daran erinnern können, wer welche Note gibt, ist nicht mehr möglich.
Und dann kommt die Lösung von selbst. Um die Belastung eines Teams erfolgreich zu regulieren, ist es erforderlich, nicht nur eine allgemeine Aufzeichnung in den Verlaufspunkten zu führen, sondern auch eine separate Aufzeichnung im Zusammenhang mit der Belastung auf der Vorder- und Rückseite. Auf diese Weise können Sie den optimalen Arbeitsaufwand für jeden Bereich ermitteln und sich darauf verlassen, dass er den Sprint-Rückstand ausfüllt. Bisher kann dieser Ansatz in Jira nicht ohne separate Hinweise in MS Excel implementiert werden. Dies bedeutet jedoch nicht, dass er nicht verwendet werden sollte.
Ich bin sicher, dass Atlassian-Entwickler eine Lösung für dieses Problem finden werden, aber wiederholen Sie vorerst nicht unsere Fehler!
PS Diese Schlussfolgerungen gelten nur für die Entwicklung von Client-Server-Anwendungen, bei denen die Arbeit im Front- und Backend klar voneinander getrennt ist. Ein solches Problem sollte nicht im Team der Full-Stack-Entwickler auftreten, die die Arbeit sofort in zwei Richtungen bewerten.