Im fünften und letzten Schritt kommt die eigentliche Kontrolle ins Spiel. Jeder Entwickler hat seine Tasks und das am besten in einem Tools wie Assembla erfasst und in Eclipse integriert. So ist der Kunde und auch der Entwickler jederzeit im Bilde, über das was gerade getan wird und das was noch getan werden muss. Und das geht genau so:
Ein Entwickler nimmt sich einen Tasks (vom Projektleiter zugeordnet oder freiwillig) in dem er in als (zu sich zugeordnet markiert) in Bearbeitung. Jeder kann also sehen, aha, der Entwickler XY ist gerade am Tasks ABC dran. Wenn der Entwickler dann diesen Tasks abgearbeitet hat, schreibt er in den Tasks, wie lange er dafür benötigt hatte.
Wenn nun alle Tasks für dieses Projekt im Scrum-Tool erfasst wurden und noch netter Weise mit den geschätzen Stunden, dann kann man sehr einfach erkennen, ob das Projekt im Plan liegt oder nicht und der Abgabetermin in Gefahr ist.
Denn wenn man zb. nach 3 Wochen schon sieht, das alle Entwickler ca. 10% länger Zeit benötigt haben, als zuvor geschätzt, dann wird zumind. dieser Sprint zeitlich 10% später fertig werden. Logisch, oder? Auch logisch ist dann, das wenn es zb. 8 Sprints für dieses Release gibt und sich jedes um 10% verlängert, das gesamte Projekt bzw. Release nie in der geplanten Zeit fertig sein wird.
