Scrum und XP im harten Projektalltag
Scrum und XP im harten Projektalltag
Scrum und XP im harten Projektalltag
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
SO SIEHT UNSER PRODUCT BACKLOG AUS| 11<br />
Dokument mitnutzen. Egal, ob um nur etwas nachzulesen, oder<br />
Schätzungen nachzubessern.<br />
Aus diesem Gr<strong>und</strong> speichern wir es auch nicht in der Versionskontrolle<br />
sondern auf einem Netzwerklaufwerk. So hat jeder Zugriff, ohne dass wir<br />
uns mit gesperrten Dokumenten oder Konflikten be<strong>im</strong> Zusammenführen<br />
herumärgern müssen.<br />
Alle anderen Dokumente kommen selbstverständlich ins Repository.<br />
Zusätzliche Story-Felder<br />
Gelegentlich verwenden wir zusätzliche Felder, um dem Product Owner<br />
das Priorisieren der Stories zu erleichtern.<br />
� Bereich – Grobe Kategorisierung der Stories, z.B.<br />
"Adminbereich" oder "Opt<strong>im</strong>ierung". Mit ihr kann der Product<br />
Owner auf einen Schlag alle Einträge zum Thema "Opt<strong>im</strong>ierung"<br />
herunter priorisieren.<br />
� Komponente – Meistens sind das Checkboxen <strong>im</strong> Excel-<br />
Dokument, z.B. "Datenbank", "Server" oder "Client" mit denen<br />
das Team die <strong>im</strong> Rahmen der Story anzupassenden technischen<br />
Komponenten identifiziert. So können Stories spezialisierten<br />
Teams (z.B. dem Datenbank-Team) leichter zugeordnet werden.<br />
� Urheber – So erinnert der Product Owner sich daran, wer das<br />
Feature angefragt hat <strong>und</strong> kann ihn über den Status auf dem<br />
Laufenden halten.<br />
� Bugtracker-ID – Wer ähnlich wie wir ein Bugerfassungssystem<br />
verwendet, kann so den Zusammenhang von Story <strong>und</strong> Bugs<br />
dokumentieren.<br />
Wie wir das Product Backlog in<br />
K<strong>und</strong>ensprache halten<br />
Product Owner mit technischem Hintergr<strong>und</strong> neigen dazu, Stories<br />
technische Namen wie z.B. "EVENT-Tabelle um Datenbankindex<br />
erweitern" zu geben. Die Frage ist aber: Was interessieren Ihn<br />
Datenbankindizes? Geht es nicht um das Thema "Performance der<br />
Veranstaltungs-Suche verbessern"?<br />
Alle sind besser damit beraten, wenn das Team entscheidet, wie es<br />
fachlichen Anforderungen des Product Owners konkret umsetzt. Denn oft<br />
sind es gerade nicht die fehlenden Datenbankindizes, die zu schlechten<br />
Antwortzeiten führen.
Change language