Die Geschichte, die mit einer einzigen E-Mail beginnt, endet damit, dass das Team sechs Wochen lang nichts anderes entwickelt.

Die erste Benachrichtigung ist unkompliziert: Ein Ereignis auswählen, eine Vorlage rendern, versenden. Die zweite ist ebenfalls unkompliziert. Die zehnte ist der Moment, in dem dem Team bewusst wird, dass es seit zwei Monaten ein Benachrichtigungssystem entwickelt, ohne sich dies einzugestehen. Einstellungen, Zusammenfassungen, Dublettenfilterung, „Nicht stören“-Zeiträume, kanalbezogene Übersteuerungen (von denen keine im ursprünglichen Ticket enthalten war) – all dies wird in dem Moment unverzichtbar, in dem ein Benutzer um 3 Uhr morgens benachrichtigt wird.

Beurteilen Sie das System, nicht die E-Mail. Das Team, das dafür stimmt, „eine Slack-Nachricht zu senden, wenn X eintritt“, unterschätzt den Aufwand um eine Größenordnung, da es nur eine Zeile in einer Tabelle berücksichtigt, die letztendlich dreißig Zeilen umfassen wird.

Was in dem Raum gesagt wird

Backend: „Das Versenden der E-Mail ist ein eintägiges Ticket.“

PM: „Können Nutzer diese Funktion deaktivieren?“

Backend: „Pro Ereignis oder global?“

Designer: „Wie sieht die Seite mit den Einstellungen aus?“

SRE: „Was passiert, wenn der E-Mail-Dienst ausfällt? Erneuter Versuch? In die Warteschlange stellen? Verwerfen?“

Support: „Wie erklären wir einem Nutzer, warum er die E-Mail nicht erhalten hat?“

Fragen, die man sich vor der Stimmabgabe stellen sollte

  • Heute nur ein Kanal, oder richten wir von Anfang an E-Mail, Push-Benachrichtigungen und Slack ein?
  • Benutzereinstellungen: Globale Umschaltfunktion, pro Ereignis oder pro Kanal?
  • Deduplizierung und Digests: Jetzt erforderlich oder „später“?
  • Zustellungsgarantien: mindestens einmal, höchstens einmal, genau einmal?
  • Prüfpfad: Kann der Support einem Benutzer mitteilen, warum eine Benachrichtigung nicht angekommen ist?
  • Vorlagen: Wer verfasst den Text, wer lokalisiert ihn, und wo wird er gespeichert?

Die ehrliche Zahl bezieht sich auf „den Tisch mit den dreißig Plätzen“, nicht auf „die erste Reihe“. Wenn das Publikum nur die erste Reihe sehen kann, ist die Geschichte noch nicht ausgereift; trennen Sie daher den einen Kanal,/guides/agile-estimation-guide/splitting-user-stories/ den Sie derzeit benötigen, von dem System, in das Sie sich später hineinentwickeln werden.

Beurteilen Sie das System, nicht die E-Mail. Die erste Benachrichtigung betrifft einen Tag; die dreißigste betrifft das gesamte Projekt.

Ähnlich wie bei der Schätzung einer Zahlungsintegration gibt die öffentliche Oberfläche keinen Aufschluss über den tatsächlichen Arbeitsaufwand. Sehen Sie sich die anderen Beispiele für durchgeführte Schätzungen an oder starten Sie eine kostenlose Planning-Poker-Sitzung, sobald die Tabelle skizziert ist.