Hallo zusammen,
Ich habe mal eine (Off-Topic) Frage zu Euren Erfahrungen. Ich bin gerade dabei bei einem Kunden Scrum einzuführen. In Kürze haben wir unser erstes Backlog-Grooming Meeting (5 Tage vor Beginn des ersten Sprints). In diesem Meeting möchte ich
- Product Backlog verfeinern
- User Stories und DoDs aufbereiten
- Aufwände schätzen
Für die Aufwandsschätzung habe ich Poker Cards und ich möchte die Aufwände in Stunden schätzen lassen (ich weiß, hier gibt es abstraktere Ansätze aber ich möchte es mal so versuchen).
Die Frage die sich mir dazu stellt:
Es ist ein relativ kleines Team (4 Personen). Wir haben einen Tester, zwei Entwickler und einen Infrastruktur-Verantwortlichen. Nun gilt es zB. einen Task “Suchen von Produkten anhand der Artikelnumer” zu schätzen. Wie lasst ihr das dann schätzen? Zwei der vier Mitglieder haben von dem Aufwand nur bedingt Ahnung und die Entwickler könnten sich mit den Schätzungen für das Testen schwer tun.
Habt ihr hier Erfahrungen in Euren Teams gesammelt?
Bin gespannt,
liebe Grüße,
Synonymous
Das ist doch ein Aspekt von Scrum… die Maßgabe ist zunächst “Schätzt halt mal”, in deinem Fall erst mal “Aus dem Bauch raus”.
Daraus ergibt sich dann die Dauer und Arbeitsmenge an einen Sprint. Die sogenannten Story Punkte aller Arbeitspakete des Sprints werden zusammengezählt (Ergebnis des Pokers) und gesagt, in einer Woche (also einem Sprint) schaffen wir 30 Story Punkte (Werte jetzt frei erfunden). Merkt man, dass man nur 10 Story Punkte geschafft hat, war entweder der Sprint zu voll und man muss sein 30 anpassen, oder die Schätzung lag voll daneben… das würde dann im nächsten Planning Poker berücksichtigt.
Das Pokern dient nicht dazu ein Gantt Chart für das gesamte Projekt zu malen. Das wäre im Wiederspruch zum agilen Programmieren.
1 „Gefällt mir“
Hi,
sehe das ähnlich wie Ancillius. Im allerersten Sprint Planning kann man eigentlich nur “falsch” planen. Das Team muss diese Mechanik erstmal lernen und mit jedem Planning wird das auch besser werden. Mit der Zeit wird sich das angleichen. Was immer ganz gut hilft und wir auch so machen: Angenommen zwei Leute vergeben 3 Story Points, einer 1 SP und der letzte 5 SP. Dann müssen die beiden, die so “ausreißen” erklären, warum sie das so einschätzen. Oft sind das entweder Leute die keine Ahnung von dem Ticket Thema haben, oder genau umgekehrt sehr viel Ahnung haben. Der Ausschlag kann dann natürlich auch in beide Richtungen gehen. Dabei kann man dann ganz gut einen Mittelweg finden.
Wichtig finde ich auch immer, dass die Tickets einen möglichst genauen Task haben und abschließbar sind. Tickets wie “Bau mir ein neues Backend Modul” kann man nicht einschätzen und planen. Besser wäre, solche Tickets aufzuteilen in: “Baue einen Menüpunkt, der das Backend Modul öffnet”, “Baue ein Listing für das Backend Modul”, “Baue eine Detailseite für das Modul”.
Beachte das die Einführung von Scrum selbst ein agiles Projekt ist 
Also von heute auf morgen sagen, wir machen Scrum, wird nicht funktionieren. Es wird am Anfang große Probleme geben und das musst du dem Team bewusst machen. Diese Probleme müssen dann in der Retrospektive angesprochen werden und beseitigt werden. Sprint für Sprint wird so die Arbeitsweise klarer und besser werden.
Viel Spaß bei der Einführung von Scrum!
Viele Grüße aus Schöppingen
Michael Telgmann
1 „Gefällt mir“
Guten Morgen,
Vielen Dank für Eure Inputs. Das die Einführung von Scrum nicht von heute auf morgen funktioniert, ist mir bewusst. Allerdings gab es bisher - auch aufgrund des kleinen Teams - gar kein Prozessmodell um Anforderungen umzusetzen. Sämtliche Wünsche wurden Face-2-Face mit dem Entwickler besprochen oder in unser Bugtracking-System eingetragen. Eine Ressourcenplanung oder Terminisierung gab es bislang kaum. Das war auch einige Zeit vertretbar und ein geeigneter Ablauf aufgrund der Teamgröße.
Das eigentliche Problem ist dabei, dass das Entwicklungsteam allerdings ständig vor einem Haufen Arbeit steht und langsam aber sicher ausbrennt. Und die Qualität des Endprodukts ist auch nach und nach gesunken. Daher habe ich mich jetzt intensiv mit dem Agile Manifesto und den zugehörigen Modellen beschäftigt.
Meine Sorge ist nur, dass bei der heutigen Aufwandsschätzung Teammitglieder Schätzungen abgeben, obwohl sie von diesem Thema tatsächlich gar keine Ahnung haben. Wenn unser Sysadmin zum Beispiel den Aufwand für das Erstellen eines XSL:FOP Dokuments schätzen soll, wird er vermutlich nur Bahnhof verstehen.
Aber ich habe Eure Argumente verstanden und werde das heute mittels Planning Poker ausprobieren. Ich lasse Euch wissen wie es gelaufen ist 
Liebe Grüße,
Synonymous