Umgang mit Fehlern mit Scrum

Bei meinem aktuellen Projekt verwenden wir Scrum, um eine Anwendung zur Datenverarbeitung und -veröffentlichung zu entwickeln. Unser Ziel ist es, in jedem Sprint funktionierende, getestete Software zu liefern. Unser Team besteht aus Testern, die die von uns erstellte Software testen, während wir sie entwickeln. Alle Fehler, die sie finden, versuchen wir zu beheben, sobald sie entdeckt werden. Manchmal können Fehler jedoch nicht in dem Sprint behoben werden, in dem sie gefunden werden. Diese Fehler müssen mit Hilfe des Scrum-Prozesses behoben werden. Wir verwenden dafür den folgenden Prozess. Am Ende eines Sprints werden alle ungelösten Fehler, die von den Testern als wichtig oder höher eingestuft wurden, als separate Punkte in das Product Backlog eingetragen. Probleme von geringerer Bedeutung werden in unserem Bugtracking-Tool gesammelt. In der Planungssitzung für den nächsten Sprint wählen die Product Owner die Punkte mit der höchsten Priorität (einschließlich Bugs) aus dem Product Backlog aus, die in das Sprint Backlog aufgenommen werden sollen. Punkte, die nicht ausgewählt werden, verbleiben im Product Backlog, möglicherweise für die nächsten Sprints. Dieser Prozess bietet Transparenz über die Arbeitsbelastung der Product Owner, sowohl in Bezug auf die zu entwickelnden User Stories als auch auf die ausstehenden Probleme. Sie können über die relative Priorität dieser Probleme entscheiden und haben so die volle Kontrolle über den Umfang des Sprints. Außerdem wird so eine Brücke zwischen unserem Problemverfolgungssystem und dem Scrum-Prozess geschlagen und sichergestellt, dass es sich nicht um zwei getrennte Welten handelt. Damit dies funktioniert, ist es wichtig, dass sich die Tester und die Produktverantwortlichen darüber einig sind, was ein großer und was ein kleiner Fehler ist. Wenn dies nicht der Fall ist, tauchen entweder unwichtige Probleme im Product Backlog auf (und werden dort höchstwahrscheinlich auch bleiben) oder, schlimmer noch, wichtige Probleme bleiben in der Kategorie "minor" und sind für die Product Owner nicht sichtbar. Ein regelmäßiger Austausch mit den Produktverantwortlichen über kleinere Probleme mindert dieses Risiko und sorgt für mehr Transparenz bei den Beteiligten.