Eines der wichtigsten Konzepte in Scrum ist die Definition von Done. Mit ihr legen das Scrum-Team und die Stakeholder fest, was genau erforderlich ist, um eine User Story abzuschließen. In der Regel umfasst es eine oder mehrere der folgenden Bedingungen: Code vollständig, vom Entwickler getestet, dokumentiert und abgenommen. In meinem aktuellen Projekt wurde das System, das wir aufbauen, vom Kunden abgenommen und befindet sich in Produktion. Gleichzeitig findet jedoch eine neue Entwicklung der Software statt. Die Bugs und User Stories, die sich aus der ersten und zweiten Aktivität ergeben, landen im selben Product Backlog und werden vom selben Scrum-Team bearbeitet. Bei den User Stories schließen wir die Codierung, die Entwicklungstests und die Dokumentation in die Definition of Done ein. Das hat sich für uns bewährt und hat es uns ermöglicht, das System überhaupt erst zu erstellen. Bei den Fehlern sieht es jedoch anders aus. Dabei handelt es sich um Fehler in der bereits vorhandenen Software, die entweder von einem externen Testteam oder in der Produktion gefunden wurden. Anfangs verwendeten wir für die Bugs die gleiche Definition of Done wie für die User Stories. Bei der Bereitstellung von Softwarekorrekturen für diese Fehler stellte uns unser Kunde regelmäßig eine Reihe von Fragen, auf die wir keine Antworten hatten:
- Welche Versionen/Anwendungen sind von diesem Fehler betroffen?
- Welche Versionen müssen gepatcht werden?
- hat dies Auswirkungen auf die Schnittstelle zwischen den Anwendungen A und B?
- Gibt es eine Umgehung dafür? Wurde sie dokumentiert?
Wir haben erkannt, dass die Definition of Done für die Bugs anders sein muss als die für normale User Stories. Indem wir die obigen Fragen einbeziehen, schaffen wir Transparenz darüber, was wir bei der Lösung von Fehlern berücksichtigen müssen, und können die Erwartungen des Kunden besser erfüllen.
Verfasst von
Martin van Vliet
Unsere Ideen
Weitere Blogs
Contact