"Wird die Aufwandschätzung für eine User Story ganz normal in Stunden geschätzt und mit dem Faktor 1,33 Faktor für "real days" multipliziert oder ist der Faktor je nach Team unterschiedlich?"In den agilen Teams, in den ich bisher gearbeitet habe, gingen wir von Story Points aus. Warum? Story Points (SP) beziffern die "Groesse" (Size). Sie haben keinen zeitlichen Aspekt. Wenn man User Stories mit SP's schätzt, kann man sie nebeneinander stellen und vergleichen:
Story A ist doppelt so "viel" wie Story "B". Story "C" ist 5 man so "viel" wie Story A.Das ist sehr abstrakt und das ist gut so! Wichtig ist auf jeden Fall, dass die Story Points Scale endlich ist: z.B. 1-5, oder 10-100, etc. Sie sollte eine Progression ausdrücken, also nicht linear sein.
Reals Days ist eine andere Möglichkeit, User Stories zu schätzen.
Während des Sprint Planning Meeting 2, wenn das Team die Arbeit aufteilt, analsyisert und annimmt, werden die User Story in Tasks runtergebrochen und mit h versehen. Wenn man dann alle Stunden aller Team Members aufsummiert bekommt man eine geschätzten Aufwand für den kommenden Sprint. Legt man neben dran die Summe der verfügbaren Arbzeisstunden, kann man ungefähr erkennen, was dring liegt und was nicht.
- Beispiel: Sprint à 2 Wochen (10 Arbeitstage), Teamsize 3:
- Total verfügbare Arbeitszeit: 252 h (8.4h/Tag x 10 Tage x 3)
- Real Days: 180 h (6h/Tag x 10 x 3)
- Summe der Aufwandschätzung von n Task vom Team im Sprint Planning Meeting 2: 200h
Jedes Teammitglied fügt solche Tasks während des Springs mit verbleibender Zeit (remaining time) in h ein. Der Scrum Master legt beim Daily Scrum jeweils das Sprint Burndown Chart auf und bespricht die Situation mit dem Team. Hier wird erkenntlich, ob die remaining time mit den noch verfügbaren Stunden übereinstimmt.
Das Sprint Burndown Chart ist vielleicht mal einen extra Post gut, mal sehen ...
4 Kommentare:
Hi,
bei den Storypoints ist das einzige Problem, dass man sie nur schlecht in Geld ausdrücken kann.
Wenn mir jemand eine gewisse Sume in die Hand drücken würde und sagen würde "Mach das Beste draus!" wären die Storypoints ideal.
Doch meistens ist es ja so, dass jemand sagt: "ich möchte diese oder jene Features, wieviel kostet mich das?". Kosten entstehen hauptsächlich durch die Entwicklungszeit, also plant man auch meistens so, also in Tagen.
Wie machst du das?
Viele Grüße
Helmut
Hallo Helmut,
User Stories sollen bewusst keinen monetären,bzw. zeitlichen Aspekt haben. Sie stellen eher eine abstrakte Grösse für Arbeit dar.
Beispiel: Wenn man mit von Berlin nach Hannover reist, ist das z.B. SP=1, Berlin nach Paris SP=2 und Berlin nach New York SP=7. Der "Preis" meiner Reise hängt davon ab, welches Verkehrsmittel ich verwenden werde. Das genau, ist die Entscheidung vom Team und ist pro Person unterschiedlich. Linus Gerdemann (Rad-Profi) würde für die Wegstrecke Berlin Hannover natürlich das Bike nehmen und vermutlich >6h benötigen. Ich allerdings würde auf die Bahn setzen und nur die halbe Zeit investieren. Trotzdem ist diese Etappe wenig komplex. Nach Paris allerdings muss man bereits einplanen, dass man kein deutsch spricht, was meine Reiseplanung unter umständen beeinflusst. New York ist noch unterschiedlicher, hier muss ich noch Visa und Co. einberechnen.
Anhand dieses Beispiels wird klar, dass man bei User Stories Zeit und $ Aufwand nicht mit der Aufgabe vermischt, denn abhängig von den Personen, deren Kompetenzen und den gegebenen Rahmenbedingungen würde diese verfälscht.
Dennoch gibt es einen Ansatz, wie man die Frage "Was kostet das?" beantworten kann. Nach ein paar Iterationen hat man ein ziemlich gutes Bild darüber, wieviel Story Points das Team abarbeiten kann. Rechnet man das auf Stunden runter, bekommt man einen Durschnitt: Story Point zu Zeit, z.B. 1 SP = 2.25 Tage.
Allderings würde ich diese Umrechnung nicht zum Manifest erklären, denn:
a) Ist pro Team unterschiedlich
b) wird sich verändern, meistens posititv
c) führt zu Diskussionen mit dem Kunden
Grundsätzlich würde ich einem Kunden gegenüber so argumentieren:
Agil nach Scrum bedeutet, für den monetären Einsatz von X bekommt man in 2 Wochen einen Wert von Y, geleistet durch das Team. Die Frage, welches Feature in einer Iteration gemacht wird ist nicht unmittelbar vom Preis abhängig, User Stories haben eine Businessvalue. Ein agiler Kunde macht nicht die Frage "Was kostet das?" zur Entscheidungsgrundlage, sondern "Wie wichtig ist das Feature - Wie gross ist der Business Value?"
Konnte ich Ihre Frage beantworten?
Gruss, jp
6h/Tag nehm ich dir nicht ab, eher noch eine Stunde weniger. Was nohc fehlt ist ein eigener Task zur Vorbereitung er Demo am Ende des Sprints. Die halbe Stunde sollte man schon einplanen und nutzen.
Die vergessenen Dinge werden oft dadurch ausgeglichen dass es durch die Aufsplittung in kleine Tasks zu Redundanz kommt, man also zwei Tasks von je 4h zusammen in nur 6h erledigt.
Und, wer 100% over-commitment hat der darf virtuelle Programmierer erfinden. Kein Scheiß, hab ich erlebt und ich fand's auch ganz lustig dass diese Virtuellen an manchen Tagen auch mitgeabeitet haben ;-)
Hallo Thomas,
natürlich sind 6h/Tag jeweils relativ zu verstehen. Hier wird sich das Team auf einen Wert finden. Wir haben jeweils einen Arbeitstag von 8.5h, wobei man eben viele Meetings, andere Projekte, Weiterbildung und Hilfestellungen bei anderen einplanen muss. Daher gehen wir von 6h aus. Diesen Wert sollte man auf jeden Fall adaptieren.
Das mit der Vorbereitung der Demo ist ein interssanter Punkt. Demo ist bei uns ein Teil der Retrospective, die in 2 Teile a 4h zerfaellt. Erster Teil, Demo. Zweiter Teil Reflektion des Sprints vom Team. Das ist also ein 8h Tag, der nicht in der Planung eines Sprints auftaucht.
100% overcommitted und virtuelle Programmierer - naja, ich sachen Transparenz braucht man die wohl ;-)
Kommentar veröffentlichen