Bugs. Jeder kennt sie, jeder hat sie, keiner will sie, keiner braucht sie. Aber doch hat sie jeder, auch wir tarentler kommen oft genug ins Grübeln darüber und vertreiben uns die Zeit bis zur Lösung mit Haareraufen.

Mehr als einmal habe ich bisher als Entwickler und Scrum Master die Preisfrage gehört: „Warum schätzen wir die eigentlich nicht einfach?“

Ja warum eigentlich nicht? Warum stecken wir im Jira bei den einen Tickets Zahlen dran und bei anderen nicht? Ist das nicht zu dogmatisch? Wo beginnt denn der Pragmatismus, denn den braucht man doch ohnehin in unserer agilen Welt, oder? Pragmatismus ist gut. Solange er nicht die Richtlinien bzw. das Regelwerk, was man sich ausgesucht hat, komplett aushebelt und verbiegt. Setzen wir also mit dem Schätzen von Bugs das imaginäre Brecheisen an?

Aus der Sicht eines Entwicklers gestaltet sich das folgendermaßen: „Unsere Velocity geht runter, aber nur weil man gar nicht sieht, wie viel Arbeit wir eigentlich geschafft haben. So können wir auch gar nicht planen! Die ganzen Bugs verzerren das total!“

Ist das plakativ geschrieben? Ja. Ist das unrealistisch? Nein. Ich kann die Perspektive aus eigener Erfahrung verstehen, aber sehe auch die eines Scrum Masters: „Die ungeschätzten Bugs lösen Schmerzen bei euch aus und das ist auch richtig so. Alles was ‚wirkliche‘ Bugs sind, sprich Fehler bei der Implementierung, sollen nicht geschätzt werden, weil ihr euch auf die Schulter klopfen könntet, wenn ihr Zahlen dran schreibt und im nächsten Sprint sagt ‚Mensch, schau mal wie viel wir geschafft haben.‘ “

Ist das plakativ geschrieben? Ja. Ist das unrealistisch? Nein. Handelt es sich nicht um Fehler der Implementierung, dann sollte überlegt werden, ob es sich nicht um eine neue Anforderung, eine nicht mitgeteilte Anforderung oder ähnliches handelt, was wiederum als neue geschätzte Story einfließen kann. Handelt es sich um Fehler der Implementierung, dann sollen diese Schmerzen verursachen. Das Scrum Team sollte sich zusammensetzen und überlegen, woran es liegt und wie es angegangen werden kann.

Dennis Berthold, Scrum Master und Softwareentwickler