Wir sind ein kleines Team (3 Entwickler und 2 Tester) und setzen Scrum seit 6 Monaten erfolgreich ein, obwohl wir für diese Methodik ein wirklich kleines Team sind. Ich bin ein Rookie als Scrum Master.
Jetzt haben wir begonnen, Probleme mit Sprints zu haben, die mit Tickets enden, die von Entwicklern fertiggestellt wurden - theoretisch -, aber der Tester hatte nicht genug Zeit, um sie zu testen.
Wie sollen wir damit umgehen? Eine Verlängerung des Sprints ist nicht erlaubt, also scheint das Verschieben der Tickets in den nächsten Sprint in Ordnung zu sein, aber wie könnten wir sie einschätzen? Da Tester große Probleme finden konnten, die zu neuen Korrekturen führen könnten.
Bearbeiten: Weitere Informationen: Wir hatten 7 Tickets ... dieses Hauptticket wurde zuerst genommen und es dauerte vom Start bis zum Ende des Sprints, also haben wir nur EIN fertiges Ticket. Es ist der seltsamste Sprint, den wir hatten. Natürlich: die schlechteste Schätzung aller Zeiten, aber unsere Retrospektive wird mit nur einem fertigen Ticket und dem anderen mit abgeschlossener Entwicklung, aber ohne Test so seltsam aussehen ... Was soll ich administrativ tun? zurück in den Rückstand und neu anfangen? Schätzung des ursprünglichen Story Points - Entwicklungszeit (die bereits "fertig" ist)?
Sie müssen Ihren gesamten Schätzungs- und Zielsetzungsprozess überprüfen und anpassen. Kurzfristig sollte jedoch unvollständige Arbeit wieder in das Product Backlog gestellt, neu priorisiert und neu bewertet werden.
Was soll ich administrativ tun? zurück in den Rückstand und neu anfangen? Schätzung des ursprünglichen Story Points - Entwicklungszeit (die bereits "fertig" ist)?
Du solltest ein Sprintziel haben. Das Ziel eines Sprints ist es, das Sprintziel zu erreichen, nicht viele Tickets zu erledigen. Ohne ein Sprint-Ziel halten Sie sich nicht wirklich an das Scrum-Framework und können den Erfolg des Sprints nicht richtig bewerten.
Ungeachtet dessen bezieht sich Ihre spezifische Frage darauf, was mit Arbeit zu tun ist, die nicht wirklich erledigt ist . Wenn Ihre Definition of Done den Abschluss der QA beinhaltet, dann ist das Product Backlog Item einfach unvollständig. Es ist nicht teilweise fertig, es ist nicht irgendwie fertig, es ist einfach nicht fertig.
Wenn Product Backlog Items am Ende eines Sprints nicht vollständig sind, gehen sie zurück in das Product Backlog, um vom Product Owner neu priorisiert zu werden . Das Element kann relevant bleiben oder nicht, und nur der Product Owner kann feststellen, ob es noch sinnvoll ist, Ressourcen dafür in einem zukünftigen Sprint zuzuweisen.
Wenn die Arbeit wieder in den Geltungsbereich der Backlog-Verfeinerung oder der Sprint-Planung kommt, muss die Arbeit neu geschätzt werden. Der Scrum-Guide sagt:
Alle unvollständigen Product Backlog Items werden neu geschätzt und wieder in das Product Backlog aufgenommen. Die an ihnen geleistete Arbeit entwertet sich schnell und muss häufig neu eingeschätzt werden.
Wie viel Arbeit an dem Artikel zuvor geleistet wurde, ist irrelevant. Die Arbeit muss neu eingeschätzt werden, um zu ermitteln, wie viel Aufwand noch verbleibt (unter Berücksichtigung des Wissens über die aktuelle Teamkapazität und der gesammelten Erfahrungen), um das Feature innerhalb eines neuen Sprints zu implementieren. Historische Schätzungen und aufgewendeter Aufwand sollten als Datenpunkte verworfen werden, da Zeitfenster vergänglich sind; Was zählt, ist der verbleibende Aufwand.
Es gibt eine Grenze dafür, wie viele Ratschläge von Fremden im Internet eingeholt werden können. Ihr Team ist sich vermutlich des Problems bewusst und Scrum schreibt ein sich selbst organisierendes Team vor. Diskutieren Sie also das Problem und machen Sie während der Retrospektive ein Brainstorming/bewerten Sie mögliche Lösungen.
Davon abgesehen...
Insbesondere während der Schätzung. Schätzungen sollten sich auf den Aufwand beziehen, der erforderlich ist, um die Geschichte fertig zu stellen℠, und nicht nur auf die Entwicklung. Davon abgesehen...
Sie vervollständigen also nicht alle Geschichten, okay, keine große Sache. Erreichst du dein Sprintziel? Darauf sollten Sie Ihre Bemühungen konzentrieren. Wenn Sie Ihr Sprint-Ziel vollständig in der Entwicklungsphase haben, aber die QA hinterherhinkt, wäre es vielleicht das Beste für die Entwickler, die „Stretch“-Geschichten zu ignorieren und stattdessen der QA zu helfen? Nur ein Vorschlag - wenden Sie sich erneut an das Team.
Wenn Sie kein Sprintziel haben , dann haben Sie größere Probleme als unvollständige Stories.
Jetzt haben wir begonnen, Probleme mit Sprints zu haben, die mit Tickets enden, die von Entwicklern fertiggestellt wurden – theoretisch –, aber die QA hatte nicht genug Zeit, um sie zu testen
Schätzung des ursprünglichen Story Points - Entwicklungszeit (die bereits "fertig" ist)
Versuchen Sie, das Testen nicht als QA-Aktivität zu betrachten. Es ist eine Teamaktivität .
QAs können Tests durchführen, aber sie müssen auch mit dem Product Owner/den Entwicklern über Probleme sprechen, und Fehlerbehebungen werden normalerweise die Entwickler einbeziehen. Berücksichtigen Sie auch Aktivitäten wie Ursachenanalyse, Testautomatisierung, Metriken zur Codequalität usw.
Wenn der Test nicht erfolgreich abgeschlossen wird, ist das Ticket einfach nicht erledigt . Bringen Sie es in den Rückstand zurück, und wenn es erneut priorisiert wird, müssen Sie es erneut schätzen.
Wir hatten 7 Tickets ... dieses Hauptticket wurde zuerst genommen und es dauerte vom Start bis zum Ende des Sprints, also haben wir nur EIN fertiges Ticket
Dies ist eine hervorragende Gelegenheit zum Lernen. Überlegen Sie als Team, warum dies passiert ist. Was kann getan werden, damit es in Zukunft nicht mehr passiert?
aber wie könnten wir sie schätzen? Da die QA große Probleme finden könnte, die zu neuen Korrekturen führen könnten.
Aus diesem Grund wenden viele Scrum-Teams Ansätze wie testgetriebene Entwicklung und verhaltensgetriebene Entwicklung an. Fehler sind notorisch schwer einzuschätzen, daher ist es sinnvoll, Zeit damit zu verbringen, sie zu verhindern, anstatt sie zu beheben.
Daniel
Sarow
Todd A. Jacobs