Story Points, Real Days und Tasks - Wie schätzt man Aufwand nach SCRUM

Eine interessante Frage, die ich kürzlich gestellt bekommen habe:

"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

In diesem Beispiel sind 20h zu viel im Sprint Backlog - es sollte etwas entfernt und ein Puffer eingeplant werden. Erfahrungsgemäss hat das Team beim Herunterbrechen der Task Dinge vergessen, die dann bei der täglichen Arbeit auffallen.

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 ...

Was meint man mit Persona?

Im Anschluss an meinen Vortrag zum Thema "Wie funktioniert agile Softwareentwicklung mit Scrum" vom 28. Mai 08 wurde ich darauf angesprochen, dass ich mich bei der Mehrzahl von Person in meiner Präsentation verschrieben habe - Personas - ein Missverständnis.

Gemeint war nicht Personen im Sinne der Mehrzahl von Person, sondern Personas im Sinne der Mehrzahl von Persona.

"Eine Persona ist ein häufig eingesetztes Modell aus dem Bereich der Mensch-Computer-Interaktion"
(Wikipedia)

Wie funktioniert agile Software Entwicklung mit SCRUM?

Zum Thema "Wie funktioniert agile Software-Entwicklung" werde ich am 28. Mai bei der Internet-Briefing Entwickler Konferenz einen Vortrag halten.

Neben ein bischen Theorie rund um Scrum werde ich der Frage nachgehen, wie eine agiles Team aussieht, wie man einen Sprint abwickelt und welche Tools man dazu einsetzt. Der Vortrag ist für Projektleiter, Produkt Manager, Entscheidungsträger und Entwickler ausgelegt - es ist also für jeden Betrachtungswinkel etwas dabei.

Den Vortrag "Wie funktioniert agile Software-Entwicklung mit SCRUM" kann man hier runterladen.

Orbit-iEX Zürich

Mein Arbeitgeber, die namics ist auch dieses Jahr an der Orbit-iEX Zürich mit einem Stand vertreten. Es gibt Referate zu den Top 11 Internet-Themen und einen eindrucksvollen Stand, wie ich finde! 100% namics, das ist auf jedenfalls einen Besuch wert.

Marcello Leonardi, ein Arbeitskollege mit dem ich unser erstes agiles Projekt bei der namics bestritten habe, wird bei der Orbit-iEX Zürich ein Referat über Software-Innovationsprojekte halten:

"Können Software-Innovationsprojekte gefördert, geplant und geführt werden?", Mittwoch, 21. Mai 2008, 09:15 – 10:45 Uhr, Anmeldung

Marcello und ich werden auf der Orbit-iEX Zürich am namics Stand anwesend sein. Sie können uns direkt ansprechen oder Termine am Stand in der namics Lounge vereinbaren mit uns vereinbaren.

Wir freuen uns auf viele Kontakte und interessante Gespräche.

Treffen Sie uns...

100% namics
Orbit-iEX Zürich
20.-23. Mai 08
Messe Zürich, mit der Tram 11 oder 4 vom Hauptbahnhof

Scrum Breakfast in Zürich, Guideware Case Study

This month we are honored to have a special guest to the Scrum Breakfast in Zürich: Stuart Read, Professor of Marketing at the IMD in Lausanne.

You already know Scrum. You have likely seen it at work. In this discussion, we will investigate a firm built completely on Scum. Not only does the firm use Sprint teams for every function in the company, the firm has used Scrum since its founding day. I encourage you to review the case study so we can have a focused discussion on the issues around such a complete adoption of the methodology, especially as the firm expands beyond 500 employees.

Stuart Read is Professor of Marketing at IMD. He is currently developing cases and research in the following areas:

• New ventures and innovation
• Specifically investigating expertise in the entrepreneurial domain
• Marketing of innovations with network externalities
• Non-predictive strategies that enable managers to effectively make decisions in situations of true uncertainty

His academic credentials include a Ph.D. in marketing from the University of Washington and a Bachelor's degree in computer science from Harvard University. He has nearly 20 years of industry experience, having participated in the creation of six high technology start-up firms. Four of those firms were acquired by industry leaders including Sun Microsystems and Lotus Development Corporation. Two are publicly traded. Stuart also spent 6 years with enterprise database software provider, Oracle Corporation.

The Scrum Breakfast in Zürich is a monthly exchange of information around Scrum. The breakfast offers discussion, information and hands-on experience to CIO's, executive and operational project managers. The Scrum Breakfast takes place the first Wednesday of each month. The program starts with a short presentation about on an in interesting topic around Scrum. Then follows a moderated discussion among the participants to encourage an exchange of know-how and experiences.

The talk will be held in English.

Attendance is free and our sponsor namics provides the coffee, gipfeli (croissants) and orange juice.

Date: June 4, 2008
Time: 10:00 to 12:30 (Special Case!)
Location: namics ag, konradstrasse 12, 8005 zürich

Registration for the Scrum Breakfast via xing or via comment (won't be published). If you wish to join us for lunch, please register separately at xing.

amazee ist seit 05. Mai 08 online

Amazee verabschiedet sich mit dem heutigen Tag offiziell aus der private Beta Phase und ist nun für alle und jeden offen.

Ladies & Gentlemen, register and start your engines projects!

Für alle, die sich noch nicht mit Amazee auseinander gesetzt haben:
Amazee ist eine Plattform die es ermöglicht, weltweit Gleichgesinnte zu erreichen und Projekte zu initiieren. Welche Ziele man auch immer anstrebt, Amazee bietet die Möglichkeit, sie bekannt zu machen und gemeinsam umzusetzen. Egal ob kleine oder grosse Lebensziele.

Der Schwerpunkt liegt auf gesellschaftlicher Zusammenarbeit zwischen Privatpersonen und nicht unbedingt auf geschäftlicher Team- und Projekt-Collaboration. Bei Amazee kann man mit anderen zusammenarbeiten, mit dem Fokus auf Ziele und Projekte.

Mehr gibt es bei Amazee's Learn more...

Zeitgleich mit dem Beta-Launch lanciert Amazee einen Wettbewerb, bei dem es in den nächsten Monaten darum geht, mit seinem Projekt Aufmerksamkeit, Unterstützung und eine möglichst grosse Gefolgschaft aufzubauen.

Der Amazee-Contest findet in drei Phasen statt. Zunächst zählt das User-Rating der teilnehmenden Projekte. In Phase zwei geht es dann darum, möglichst viele Mitglieder für das eigene Projekt zu gewinnen. Schlussendlich entscheidet eine Jury, wie der Gesamtpreis unter den Top 3 Projekten aufgeteilt wird.

Die drei Sieger-Projekte werden durch Amazee mit insgesamt € 10'000 unterstützt.

You broke the build

Auf meinem Blog schreibe ich meist über methodische Punkte rund um Scrum und/oder XP. Dabei beziehe ich mich immer auf Erfahrungen, die ich in Verbindung zu diesen Themen mache. Kürzlich hatte ich ein Erfahrung, die sich so gestaltete:

Das Set
Mehrere Entwickler arbeiten an verschiedenen Standorten an einem Software-Entwicklungsprojekt. Es gibt Entwickler, die sich ausschliesslich bei der Implementierung innerhalb eines Layers befinden, z.B. Backend, Business Services oder Web Container. Oft haben die Entwickler layerübergreifend nicht die Einsicht, von wem, wo und zu welchem Zeitpunkt Methoden aufgerufen werden.

Das Problem
Veränderung! Service Interfaces stellen einen Contract dar. Ein Änderung des Contract muss also allen Beteiligten mitgeteilt werden. So gedacht und durchgeführt von einem Entwickler, der an einem Standort die Runde per Zuruf informiert, dass er ein Interface ändern werde. Die Entwickler an anderen Standorten bekommen diese Information nicht. Der besagte Entwickler ändert das Interface und checkt den Code ins Repository ein. Alle Entwickler haben beim nächsten sync mit dem Repository nicht kompilierbaren Code. Der automatisierte Build failed in der Folge und alle Entwickler werden per Email benachrichtigt.

Was ist passiert?
Ein Entwickler hat für geschlagene 3 1/2h das gesamte Entwicklerteam mit seinem Checkin lahm gelegt.

Wie umgeht man das?
Zunächst mal sei gesagt, dass genau dieses Problem oft vorkommt und das Konzept von continuous integration aus den Angeln hebt. Hiermit soll sichgerstellt werden, das alle Veränderungen an der Codebasis, die in das Repository eingecheckt werden, die Lauf- und Funktionstüchtigkeit der Software nicht stören.

Am Beispiel eines bliebigen Interfaces möchte ich zeigen, wie man das Problem umgehen kann.

Die Methode
...
public void doSomething(String a, String b);
...

soll einen neuen Parameter bekommen:

...
public void doSomething(String a, String b, String c);
...

Wenn man das alte Interface verändert, werden alle Zugriffe auf diese Methode nicht kompilierbar sein. Man kann das wie folgt umgehen:

...
/** @deprecated */
public void doSomething(String a, String b);

public void doSomething(String a, String b, String c);
...

Die Implementierungen kann dann so aussehen:

...
/** @deprecated */
public void doSomething(String a, String b) {
// FIXME call doSomething(a,b,c) instead
doSomething(a,b, "fixed (dummy) c value");
}

public void doSomething(String a, String b, String c) {
// do stuff here
}
...


Per FIXME Kommentar kann man allen Entwicklern im Code erkenntlich machen, wie sie die neue Signatur aufrufen sollen. Wenn man das eincheckt wird nach wie vor Kompilierfähigkeit garantiert.

Natürlich muss sichgestellt werden, dass die deprecated Methode irgendwann entfernt wird. Hierfür gibt es Tools, die man im Rahmen der continuous integration laufen lassen kann. Sie raportieren TODO und FIXME Tags im Code