Backlog Refinement

In diesem Artikel erläutere ich wie ich das Refinement interpretiere und wie ich es vom Sprint Planning 1 abgrenze.

Boris Gloger gibt in seinem Video interessante Hintergrundinformationen und erläutert die Entstehungsgeschichte des Backlog Refinement Meetings. Spannend finde ich dabei wie sich der Name über die Zeit verändert hat (Estimation Meeting => Backlog Grooming => Refinement) hat.

Ziel

Mit dem Backlog Refinement soll geklärt werden, ob das, was potentiell im nächsten Sprint umgesetzt werden soll, so weit vorbereitet ist, dass es auch umgesetzt werden kann.

Konkret klärt der Product Owner mit dem Entwicklerteam, ob

• das Sprint Goal sinnvoll ist,
• die User Stories verständlich sind,
• die User Stories anhand einer groben Schätzung in den Sprint passen könnten
• und ob die Priorisierung den besten Business Value liefern kann.

Oder anders formuliert: Der Product Owner stellt sich die die folgenden Fragen:

• Habe ich das Backlog richtig priorisiert?
• Haben die Entwickler ein Grundverständnis davon, was im nächsten Sprint auf sie zukommt?
• Sind die User Stories, von denen ich tatsächlich annehme, dass sie Teil des Sprint Plannings 1 werden, S.M.A.R.T..

Beispiele

Die folgenden zwei Szenarien kennen vermutlich die meisten aus dem Alltag und zeigen, dass ein vorheriges Refinement helfen kann.

Der Product Owner stellt im Sprint Planning 1 eine User Story vor und das Team versteht diese nicht. Es entstehen lange Diskussionen, es werden Zeichnungen am Flipchart erstellt und (Domänen-)Begriffe definiert. Statt im Planning würde im Refinement frühzeitig das Verständnisproblem entdeckt und die User Story vom Entwicklerteam an den Product Owner „zurückgegeben“ werden. Der Product Owner kriegt somit Zeit die Story klarer zu formulieren oder das Feature sogar neu zu schneiden.

Eine User Story kann im Sprint Planning 1 nicht geschätzt werden, weil die Entwickler dafür zunächst technische Fragen klären müssen. Als Ergebnis des Refinements würde das Entwicklerteam den zugehörigen Quellcode nochmal untersuchen oder eine technische Gegebenheit recherchieren. Im eigentlichen Sprint Planning 1 oder einem etwaigen zweiten Refinement stünden dann alle notwendigen Informationen zur Verfügung.

Eine User Story ist deutlich größer und komplexer als der Product Owner dies vermutet hätte. Das Entwicklerteam spiegelt ihm das im Refinement, sodass er den Inhalt im Nachgang in kleinere Stücke schneiden kann.

Durchführung

Wie oft das Refinement innerhalb eines Sprints durchgeführt wird und wer daran teilnimmt, ist Geschmackssache. Nehmt die Leute mit rein, die anwesend sein müssen, um die Fragen zu klären bzw. das Ziel des Refinements zu erreichen. Und wenn der Product Owner sich ein zweites oder drittes Meeting wünscht, weil er sonst das Sprint Planning 1 nicht adäquat vorbereiten kann, dann sollten sich das Team auch Zeit dafür nehmen. Die Zeit wird ansonsten in jedem Fall im Spring Planning 1 benötigt werden (und vermutlich sogar mehr).

Gibt es bei euch ein Refinement Meeting? Wenn ja, wie trennt ihr selbiges vom Planning? Sind bei euch immer alle Entwickler oder sogar Stakeholder dabei? Schreibt es in die Kommentare.

Werbung

Datenschutzprobleme trotz Verschlüsselung?

In einem Gespräch mit unserem Datenschutzbeauftragten gab es kürzlich die Diskussion, inwieweit Dropbox als IT Cloud Speicher für Inhalte mit personenbezogenen Daten genutzt werden darf, wenn die Daten an sich verschlüsselt sind, z.B. in einer TrueCrypt Container Datei. Um eine lange Geschichte abzukürzen: Wir haben Herrn Artur König, angestellt bei der Datev eG und TÜV geprüfter Datenschutzauditor, kontaktiert. Freundlicherweise darf ich seine E-Mail Antwort veröffentlichen. Als wichtiger Hinweis sei gesagt, dass dies seine persönliche Meinung und nicht die der Datev eG wiederspiegelt.

Abschließend sei noch vermerkt, dass er mit der Aussage auch zur weiteren Diskussion aufrufen möchte, damit die Problematik in Zukunft hoffentlich eindeutig geklärt werden kann. Ich hoffe auch auf rege Beteiligung in den Kommentaren durch Datenschützer, Rechtsanwälte und IT Verantwortliche, da ich dem Thema große Bedeutung beimesse.

Ergebnis unserer Evaluierung: Wir haben uns dafür entschieden, dass die Daten in DropBox mit TrueCrypt verschlüsselt abgelegt werden.

 

…wie so oft im Datenschutz gibt es auch hier keine 100%ige Wahrheit. Diese Frage ist noch nicht abschließend geklärt und wurde z.B. beim letzten Treffen der AG Rechtsrahmen des Kompetenzzentrums Trusted Cloud des BMWi diskutiert. Die Unternehmensvertreter in dem Gremium empfahlen, eher von einer Auftragsdatenverarbeitung (ADV) auszugehen, um das Risiko einer anderweitigen Ansicht der Aufsichtsbehörde zu minimieren.

Bei Teamdrive, einer „Cloud-Lösung“ mit verschlüsselter Übertragung und Hinterlegung von Dokumenten gingen die ULD-Gutachter von einem Nicht-Personenbezug aus, wiesen aber darauf hin, dass Teamdrive trotzdem mit den Kunden / Auftraggebern  eine ADV abschließt (siehe hier).

Auch in der sonstigen täglichen Praxis wird die Verschlüsselung oft mit dem Verlust des Personenbezugs gleichgesetzt, da auch die Aufsichtsbehörden der Meinung sind, dass der Verlust eines verschlüsselten Datenträgers keine Datenpanne gemäß §42a darstellt.

Allerdings gibt es auch deutliche Argumente dafür, dass verschlüsselte Daten dennoch personenbezogen sind, so dass ich insgesamt Ihrem DSB (im Zweifel) Recht geben muss:
1.) ein heute als unknackbar geltendes Verfahren, kann in 10 Jahren durchaus knackbar sein – dies darf nicht zu Lasten der Betroffenen gehen, d.h. persönliche Daten sind auch dann zu schützen, wenn sie erst nach Jahren geknackt werden können
2.) es gibt (bis auf das One-Time-Pad, was aber für die Cloud nicht praktikabel wäre) keinen 100%igen mathematischen Beweis für die Sicherheit der heute gängigen Verschlüsselungsverfahren
3.) deshalb würde ich eine Verschlüsselung eher mit einem Safe als mit den Buchstaben-Schnipseln vergleichen, weil es eben einen Weg gibt, das Ganze reversibel zu machen (den Schlüssel)
4.) Auch im BDSG finden sich Hinweise für eine Beibehaltung des Personenbezugs: so spricht das BDSG explizit in der Anlage zu § 9 BDSG bei der Verschlüsselung von einer technischen Maßnahme – und nicht von einem tatbestandsausschließenden Merkmal des BDSG

Dagegen kann man aber auch argumentieren, indem man sich auf §3 Abs. 6 BDSG bezieht, wo von einem „unverhältnismäßig hohen Aufwand“ die Rede ist, den ich bei heute anerkannten Verschlüsselungsverfahren bejahen würde. Wie ich schon sagte, leider ist hier nichts eindeutig, von daher würde ich eine Personenbeziehbarkeit im Zweifel eher bejahen, auch wenn ich mir selbst damit schwer tue, weil man – wenn man diesen Gedanken weiter denkt – theoretisch auch keine E-Mails versenden dürfte…

Dies muss aber nicht bedeuten, dass eine Auslagerung in die Cloud grundsätzlich ausgeschlossen ist! Auch wenn man die Verschlüsselung nur als technische Schutzmaßnahme ansieht, kann damit ein Schutzniveau erreicht werden, bei dem eine Auslagerung zu rechtfertigen wäre. Bei vielen Daten ließe sich die Auslagerung damit vertreten, dass keine schwerwiegenden Beeinträchtigungen drohen, wenn diese geschützten Informationen erst nach 10 Jahren bekannt werden. Es bleibt also bei der Entscheidung im Einzelfall.  Wichtig ist hier aber, dass der Schlüssel nur beim Auftraggeber bleibt und der Dienstleister keinen „Master-Key“ hat.
Für die Auslagerung kaufmännischer Daten wäre noch §146 AO zu erwähnen, wonach die Buchhaltung im Geltungsbereich des deutschen Rechts bzw. EU-Rechts aufzubewahren ist.