Das Entwicklerteam hat immer interne Aufgaben (z. B. Umgebungsverbesserungen, Prozessverbesserungen usw.). Manchmal können sie mit dem aktuellen Projekt zusammenhängen, manchmal nicht.
Es gibt kein Problem, wenn diese Aufgaben mit dem aktuellen Projekt zusammenhängen (z. B. Continuous-Integration-Prozess für das aktuelle Projekt durchführen). Der Product Owner hat keine Einwände gegen das Hinzufügen dieser Aufgaben zum Project Backlog und kann für alle Prioritäten festlegen.
Aber was sollen wir tun, wenn diese Aufgaben häufig vorkommen und nicht mit dem aktuellen Projekt zusammenhängen (z. B. möchten wir Codekonventionen festlegen und in unserem Prozess eine automatische Codestilprüfung verwenden). Selbst wenn wir den Product Owner dazu überreden werden, diese Aufgabe zum Product Backlog hinzuzufügen, bin ich mir sicher, dass er dieser Aufgabe so wenig Priorität wie möglich einräumen wird. Und es hat Sinn für ihn, weil die Erfüllung dieser Aufgabe für das aktuelle Projekt keinen großen Nutzen bringen wird. Aber auf der anderen Seite wird es dem Entwicklerteam in aktuellen und allen anderen Projekten eine Qualitätssteigerung geben (PO kümmert sich natürlich absolut nicht um andere Projekte).
Und im Allgemeinen halte ich es für keine gute Idee, dem Product Backlog Aufgaben hinzuzufügen, die sich nicht direkt auf das Produkt beziehen .
Aber wenn wir den Product Owner nicht über diese Dinge informieren und sie nicht zum Product Backlog hinzufügen, sondern sie während Scrum tun, dann verliert Scrum seine Transparenz (eine von drei Scrum-Säulen, wie Scrum Guide sagte).
Was sollen wir also mit dieser Art von Aufgaben tun?
Dies ist ein komplexes Thema, aber die kurze Antwort lautet:
Das Product Backlog ist eine Möglichkeit für den Product Owner, die Kosten der Geschäftstätigkeit für das Unternehmen sichtbar zu machen. Das bedeutet, dass einige Teamprozess-Storys in das Product Backlog aufgenommen und richtig priorisiert werden müssen, damit Scrum funktioniert.
Betrachten Sie die folgenden Beispiele:
Als neuer Entwickler
muss ich meine Entwicklungsumgebung
so konfigurieren, dass ich produktiv an Product Backlog-Einträgen arbeiten kann.
Als Entwicklungsteam
benötigen wir einen installierten und konfigurierten Continuous Integration-Server,
damit wir sicher sein können, dass jeder Sprint ein potenziell auslieferbares Inkrement liefert.
Diese Geschichten gehören ins Product Backlog. Tatsächlich sollte die erste Story für jeden neuen Entwickler, der dem Projekt beitritt, einmal oben im Backlog hinzugefügt werden, da es etwas ist, das passieren muss, eine Ressourcenzuweisung aus dem Projektbudget erfordert und Teamkapazität verbraucht, bis der neue Entwickler eine hat funktionales Arbeitsumfeld.
Auch wenn diese Art von Geschichten dem Produkt keinen Mehrwert verleihen , fügen sie dem Projekt einen Mehrwert hinzu . Darüber hinaus besagt das Gesetz der Transparenz von CodeGnome: "Keine unsichtbare Arbeit, niemals!" Das bedeutet, dass diese Arten von Prozessgeschichten sichtbar sein müssen , da sie Arbeiten darstellen, die ausgeführt werden müssen, und das Projekt bis zu ihrer ordnungsgemäßen Implementierung belasten.
Einige Dinge, wie das Installieren einer neuen IDE, werden möglicherweise einfach als Prozessaufwand betrachtet. Die Unterscheidung zwischen Prozess-Overhead, der sich ausschließlich auf das Sprint-Backlog beziehen sollte, und Geschichten, die das Sprint-Ziel und die Kapazität des Sprints selbst betreffen, erfordert, dass jedes Team einige praktische Definitionen und Filterkriterien entwickelt.
Es gibt wirklich keine allgemein gültige Antwort, aber die Unterscheidung zwischen Overhead- und kapazitätsintensiver Arbeit muss sicherlich vom Team ausgearbeitet werden. Sobald die Unterscheidung getroffen ist, sollte der richtige Prozess für jede Art von Arbeit konsequent und mit so viel Strenge befolgt werden, wie es das Team bewältigen kann.
Der PO muss sich dessen bewusst sein, und ich würde helfen, eine Diskussion zwischen den Entwicklern und den POs zu ermöglichen, damit er die Schmerzen und kurz-/langfristigen Auswirkungen kennt, wenn er dies nicht tut. Der Versuch, Dinge unter dem Radar zu tun, ist eine großartige Möglichkeit, verärgerte Kunden (einschließlich des Bestellers) zu haben, und das Team sollte sich immer bemühen, bei Problemen, die sie haben, transparent zu sein.
Ob es in den Rückstand gehen soll oder nicht, ich würde das Team fragen, was sie tun wollen. Es wird wahrscheinlich 1 von 2 Wegen gehen:
Wenn die Aufgabe für den Entwickler wiederholt auftritt wie: „Füllen Sie Ihren Stundenzettel aus, damit Sie bezahlt werden“, ist das Overhead und geht nicht in einen Iterationsrückstand.
Wenn die Aufgabe oder Story einen diskreten, greifbaren Wert liefert, ob funktional oder nicht funktional, geht sie in das Produkt-Backlog und schließlich in das Iterations-Backlog, sobald sie vom Team priorisiert und festgelegt wurde.
Arbeiten Sie mit Ihrem Product Owner zusammen, damit er den Wert von nicht funktionalen Aufgaben versteht, da sie sich fast immer entweder auf die Qualität des Produkts oder die Fähigkeit des Teams auswirken, in Zukunft ein bestimmtes Volumen an funktionalen Elementen zu liefern.
Normalerweise, wenn ich höre, dass Entwickler in meinen Teams einen Rückstand als nicht funktionsfähig beschreiben, interpretiere ich, dass wir mit einem Rückstand arbeiten, der dem PO nicht gut genug erklärt ist, damit sie den Wert verstehen, der einige Kommunikationsarbeit erfordert.
Könnten wir die Frage wirklich präzisieren, wie wir die effektive Arbeitszeit melden?
Ich stimme Code Gnomes absolut zu - "Keine unsichtbare Arbeit jemals", aber in der Situation, in der Sie einen anhaltenden Ressourcenverbrauch haben, möglicherweise zum Beispiel außerhalb des Projekts
Ich glaube nicht, dass diese im Rückstand sein sollten, aber Sie sollten berichten, dass die effektive Arbeitszeit der Ressource weniger als Vollzeit ist. Ich weiß, dass Sie dies in TFS zeigen können, und wenn Sie einen traditionellen Projektplan beibehalten, können Sie das natürlich, aber ich kenne keine anderen Tools da draußen.
Ashok Ramachandran
Todd A. Jacobs
Ewan