. .

Warum keine Tasks im Backlog?

Vor ein paar Tagen habe ich wieder mal irgendwo gelesen, dass man doch im Backlog unterbringen müsse, dass das Team eine Entwicklungsumgebung, Testumgebung, Architektur etc. bräuchte und aufbauen müsste.

Das steht so in den ersten agilen Büchern, im ersten Buch von Ken und gehörte zu den Überlegungen, die wir, also die ersten Scrum Adopters, zwischen 2001 und 2005 gehabt haben.

Wir hatten uns geirrt. Es hat sich in den letzten 5 Jahren gezeigt, dass es nicht zielführend ist, wenn man technisch motivierte Backlog Items schreibt.

Probleme, die auftreten:

  • Was ist wichtiger, das Feature oder die Entwicklungsumgebung?
  • Der PO versteht diese Stories nicht.
  • Es sind keine Stories.
  • Das Team kann keine Velocity basierend auf solchen User Stories schreiben.
  • uvm

Heute, in meinem CSM Kurs in München, werden wir sicher wieder diese Frage vorfinden und ich kann euch versichern, dass meine Antwort immer die Gleiche sein wird: NEIN! IM BACKLOG SIND AUSSCHLIESSLICH FEATURES (also anwenderzentrierte Stories). Das hat sich bewährt und Teams zum Erfolg geführt.

Avatar of Boris Gloger
„Mut“ ist jener Wert von Scrum, mit dem sich Boris Gloger am stärksten identifiziert. Er hat in seinem eigenen Leben keine Angst vor radikalen Entscheidungen und vor dem Glauben an eine Idee. Für kein Geld der Welt würde er sich Regeln unterwerfen, die keinen Sinn machen. Er glaubt an Scrum, weil es nicht nur bessere Produkte, sondern auch eine bessere und menschlichere Arbeitswelt schaffen kann.
  • Robert Vogler

    Hallo, Boris!
    Prinzipiell gebe ich Dir aus meiner Sicht schon recht.
    Spätestens beim Review Meeting wird aber die Diskussion kommen, warum man mit den Stories nicht weiter gekommen ist.
    Und da muss man dann schon auf die “anderen” (nicht-produktiven) Arbeiten eingehen – große Hindernisse im Sprint werden ja ohnehin auch Thema sein.
    Die Architektur ist ein eigenes Thema und ist ja auch ein Produkt-Feature, könnte aber in Stories und Tasks heruntergebrochen werden. Es wird allerdings dauern, bis die Stories abgearbeitet werden, wenn die Basisarchitektur erst aufgebaut werden muss (Stichwort Tiefe und Breite).
    Ein Tipp, wie man mit der Story-orientierung in der Methode am besten umgeht, wenn die Architektur von GUI bis DB erst aufgebaut werden muss, wäre gut.
    lG Robert

    • http://borisgloger.com/members/boris-gloger/ Boris Gloger

      Hi Robert,

      1) inwiefern ist denn Architektur eine Produktfunktionalität?
      “Ein Tipp, wie man mit der Story-orientierung in der Methode am besten umgeht, wenn die Architektur von GUI bis DB erst aufgebaut werden muss, wäre gut.”
      Ich kann es nur immer wieder betonen, Architektur entsteht emergent. Also muss ich ein Feature liefern, und dann über testgetriebene Entwicklung, den Code bei jedem neuen Feature verbessern und das Design Stück für Stück anpassen und verbessern. Das funktioniert! Was es dazu braucht ist den Wollen ein Feature nach dem anderen zu bauen und nicht erst den Framework aufzusetzen.
      2) Wieso muss man auf die “anderen” Arbeiten eingehen. Das “riecht” nach Rechtfertigung.
      Wenn das Team geliefert hat, was sie versprochen haben, dann brauchen sie sich doch nicht zu rechtfertigen.
      3) Grosse Hindernisse im Sprint haben im Review nichts verloren. Was interessiert es meinen Kunden, den End-User oder die Fachabteilung welche Probleme wir hatten?

      Ich weiss, meine Position ist hier sehr klar und direkt. Die Erfahrung aus 8 Jahren Scrum hat mich jedoch gelehrt so zu argumentieren.

      • Robert Vogler

        Hallo, Boris!
        Hast Du irgendwo ein Beispiel, wie eine Architektur feature-basiert aufgebaut und wachsen kann, oder eine Literaturreferenz dazu?
        lG Robert