Erstellen eines vorzüglichen Produktrückstands
Das Team erstellt einen Produktrückstand, der normalerweise User Storys enthält, in denen die Anforderungen und Wünsche der Kunden dargestellt werden. Im Verlauf des Projekts ergänzt das Team die User Storys mit ausführlichen Informationen, gliedert sie in kleinere Storys auf, priorisiert sie und gibt Einschätzungen dafür ab. Schließlich werden die User Storys implementiert und die Ergebnisse den Kunden zur Verfügung gestellt. Durch das Schreiben von vortrefflichen User Storys und kontinuierliches Aktualisieren des Produktrückstands kann das Team die Anforderungen der Kunden effizienter erfüllen.
Bill Wake bringt die Merkmale einer gelungenen User Story mit dem Akronym INVEST (independent, negotiable, valuable, estimable, small, and testable, d. h., unabhängig, verhandelbar, wertvoll, schätzenswert, klein und testfähig) auf einen Nenner. Weitere Informationen finden Sie auf der folgenden Website: XPlorations. Mike Cohn erläutert in einem seiner Bücher, wie User Storys geschrieben werden. Sie können das entsprechende Kapitel von der folgenden Website herunterladen: User Stories Applied for Agile Software Development.
Wenn das Team eine User Story erstellt, stellen Sie sicher, dass sie für den Kunden hilfreich ist, indem die folgenden Fragen beantwortet werden:
Wer ist der Benutzer?
Was muss der Benutzer tun?
Warum muss der Benutzer dies tun?
In den meisten Fällen kann das Team dies durch Erstellen eines effektiven Titels erreichen. Mike Cohn schlägt die Form "Als <Benutzer> muss ich <Aktion>, um zu <Grund>" vor. Diesen Ansatz finden im Beispiel "Als Mitarbeiter des Kundensupports muss ich auf Kundeninformationen zugreifen, um schneller auf Kundenfragen antworten zu können". In vielen Fällen ist der Grund offensichtlich. Beispiel: "Als Vegetarier kann ich meine Ansicht so filtern, dass nur vegetarische Mahlzeiten angezeigt werden."
Die User Storys sollten außerdem auf eine Weise definiert werden, die eine Implementierung in beliebiger Reihenfolge ermöglicht. Es ist nicht immer jedoch empfehlenswert, die User Storys vollkommen unabhängig zu machen. Bill Wake und Mike Cohn erläutern beide Methoden, auf die das Team zurückgreifen kann, wenn sich das Unabhängigmachen von User Storys als kompliziert erweist.
User Storys, die, wie zuvor beschrieben, nützlich und unabhängig sind, bilden den Produktrückstand. Die User Storys werden geschätzt und priorisiert, bevor das Team damit beginnt, die Storys mit dem höchsten Rang zu bearbeiten. Bevor das Team eine User Story implementiert, muss sie die in der folgenden Liste aufgeführten Merkmale besitzen. Der Produktbesitzer muss sicherstellen, dass die User Storys mit dem höchsten Rang diese Kriterien erfüllen, bevor sie in einer Sprint-Planungsbesprechung vorgelegt werden.
Klein genug, um im Sprint implementiert zu werden
User Storys, die kurz vor der Implementierung stehen, müssen so klein sein, dass sie im Sprint fertig gestellt werden können. Der Produktbesitzer arbeitet mit dem Team, um zu große User Storys aufzuteilen. Beispiel: Die User Story "Als Mitarbeiter des Kundensupports muss ich auf Kundeninformationen zugreifen, um schneller auf Kundenfragen antworten zu können" ist möglicherweise zu groß, um in einem Sprint fertig gestellt werden zu können. Sie kann in mehrere Storys unterteilt werden, die z. B. folgendermaßen heißen: "Als Mitarbeiter des Kundensupports benötige ich Zugriff auf den Namen des Kunden und die aktuelle Anrufzusammenfassung mit der Telefonnummer des Kunden" und "Als Mitarbeiter des Kundensupports benötige ich Zugriff auf den vollständigen Anrufverlauf des Kunden, damit ich das aktuelle Problem genauer nachvollziehen kann".
Dies muss nur so genau sein, dass die zur Implementierung der Story erforderliche Arbeit beschrieben und geschätzt werden kann.
Bevor die User Storys in einen Sprint eingeschlossen werden, werden sie in Storypunkten geschätzt. Dabei handelt es sich bewusst um grobe Schätzungen, die in erster Linie zur Verwaltung des Rückstands und zur Vorbereitung auf den Sprint dienen. Wenn ein Sprint startet, gliedert das Team die User Story in die Aufgaben auf, die für die Implementierung erforderlich sind. Das Team arbeitet mit dem Produktbesitzer im Rahmen der Besprechung zum Verringern von Produktrückstand zusammen, um zu bestimmen, für welche Storys weitere Informationen benötigt werden, bevor sie in Aufgaben aufgegliedert werden können und sich der Arbeitsaufwand schätzen lässt. Der Produktbesitzer kann diese Details erfassen und sie in der Beschreibung der User Story aufzeichnen.
Achten Sie darauf, dass sie der User Story nur so viele Details wie erforderlich hinzufügen. Die User Story sollte die Grundlage für Gespräche und Verhandlungen mit dem Produktbesitzer und den Kunden sein, die so lange stattfinden, bis die User Story fertig gestellt und akzeptiert wurde. Zu viele Details können die Verhandlungen beeinträchtigen, da ein Eindruck von Genauigkeit entsteht, der nicht angemessen ist.
Definierte Akzeptanzkriterien
Am Ende eines Sprints akzeptieren die Kunden oder der Produktbesitzer die User Story entweder als fertig gestellt, oder sie lehnen sie ab. Vor Beginn des Sprints sollten die Kriterien für die Kundenakzeptanz so eindeutig wie möglich definiert werden. Natürlich kann es vorkommen, dass eine User Story aus unvorhersehbaren Gründen nicht akzeptiert wird. Allerdings kann durch die Gespräche, die das Team mit den Kunden über die Festlegung von Akzeptanzkriterien führt, sichergestellt werden, dass das Team über die Kundenerwartungen im Bilde ist. Die Akzeptanzkriterien können als Grundlage für Akzeptanztests verwendet werden, damit Sie effektiver auswerten können, ob eine User Story fertig gestellt wurde.
Epen und Themen
Es ist häufig davon die Rede, dass User Storys klein sein sollen. Dies trifft auf User Storys zu, deren Implementierung unmittelbar bevorsteht. Allerdings können Storys, die einen niedrigeren Rang einnehmen, größer sein. Tatsächlich kann durch Beibehaltung ihrer Größe verhindert werden, dass der Produktrückstand zu groß für eine ordnungsgemäße Verwaltung wird. User Storys können in kleinere User Storys aufgegliedert werden, wenn sie sich den oberen Rängen des priorisierten Produktrückstands annähern. Es ist hilfreich, sich große User Storys als Epen und Themen vorzustellen.
Epen sind sehr große User Storys, die einen beträchtlichen Arbeitsaufwand mit sich bringen. Wenn Sie ein Epos aufgliedern, werden möglicherweise viele Themen und andere kleinere User Storys erstellt.
Themen sind relativ große User Storys, die im Allgemeinen die für eine Implementierung in Sprints übliche Größe übersteigen. Bevor das Team ein Thema implementiert, muss es in kleinere User Storys aufgegliedert werden.
Wenn Sie den Produktrückstand priorisieren, gliedern Sie Epen und Themen auf, die sich im oberen Bereich befinden, und legen Sie die neuen und kleineren User Storys als Priorität fest. Wenn Sie fertig sind, sollten die User Storys mit der höchsten Priorität nur so groß sein, dass eine Implementierung möglich ist. Im unteren Bereich des priorisierten Rückstands sind die meisten User Storys im Allgemeinen größer.
Spitzen
Das Team muss gelegentlich Schritte ausführen, bei denen es sich nicht um die direkte Implementierung einer User Story handelt. Diese Arbeit wird als Spitze bezeichnet. Drei allgemeine Typen von Spitzen sind Recherche, Bug Debt und prozessbezogene oder technische Verbesserungen. Um in Team Foundation eine Spitze zu erstellen, erstellen Sie eine User Story-Arbeitsaufgabe, legen Sie als Typ "Spitze" fest, und priorisieren Sie sie anschließend im Produktrückstand zusammen mit den anderen User Storys.
Recherche
Recherche findet statt, wenn es offene Fragen zu einer User Story gibt, die beantwortet werden müssen, bevor die User Story vollständig in Aufgaben aufgegliedert und geschätzt werden kann. Beispiel: Das Team stößt während einer Besprechung zur Sprintplanung auf die Story "Als Vielflieger kann ich ermäßigte Flüge buchen". Nach Erörterung der Story sind mehr Fragen aufgeworfen worden als beantwortet wurden. Das Team erstellt eine User Story, um die Spitze darzustellen. " "Als Teammitglied weiß ich, worum es sich bei der "Buchung von ermäßigten Flügen" handelt, so dass ich Storys schreiben kann, die in zukünftige Sprints einbezogen werden." Das Team entscheidet, wie viele Stunden es der Recherche widmen möchte und legt die entsprechende Zahl als Zeitrahmen für die Spitze fest. Keine der Storys, die während der Spitze geschrieben werden, kann während dieser Iteration durchgeführt werden. Die Arbeit muss mit dem Produktrückstand für eine zukünftige Iteration geplant werden.
Bug Debt
Fehler sollten am besten unmittelbar nach dem Erkennen behoben werden. Wenn Sie den Fehler nicht an dem Tag beheben können, an dem Sie darauf aufmerksam geworden sind, erstellen Sie eine Fehlerarbeitsaufgabe, um sicherzustellen, dass sie den Fehler nicht aus den Augen verlieren. Vermeiden Sie die Anhäufung von Fehlern. Wenn das Team Fehler anhäuft, erstellen Sie eine User Story, und verknüpfen Sie die Fehler mit der Spitze, damit sie zusammen mit anderen User Storys und Spitzen geschätzt und priorisiert werden kann.
Prozessbezogene oder technische Verbesserungen
Das Team nimmt prozessbezogene oder technische Verbesserungen vor, die die Erfolgsquote verbessern. Verbesserungspotenzial wird häufig bei Sprintretrospektiven und täglichen Scrumbesprechungen erkannt. Das Team muss z. B. ggf. die Codeabdeckung durch Komponententests verbessern oder die Buildzeit auf dem fortlaufenden Integrationsserver reduzieren.