Beispiele für durchgeführte Kostenvoranschläge

So bewerten Sie eine Anmeldefunktion: der verborgene Umfang (Passwortzurücksetzung, 2FA, Föderation, Ratenbegrenzung, Sitzungen) und die Fragen, die geklärt sein müssen, bevor eine Abstimmung stattfindet.

So schätzen Sie den Aufwand für eine SSO-Integration ein: Der Aufwand liegt nicht in Ihrer Codebasis, sondern in den Besonderheiten des Identitätsanbieters. Die Fragen, die Sie klären sollten, bevor Sie eine Zahl festlegen.

So schätzen Sie den Aufwand für eine Zahlungsintegration ein: Sandbox vs. Live-Umgebung, Rückerstattungen, Webhooks, Idempotenz, PCI-Geltungsbereich. Die Gespräche, die geführt werden müssen, bevor konkrete Zahlen feststehen.

Wie man eine Suchfunktion einschätzt: Relevanz, Ranking, Facettierung und die Frage, wem der Index gehört. Die Fragen, die aus dem einfachen „Hinzufügen einer Suchleiste“ eine fundierte Einschätzung machen.

Wie man ein Benachrichtigungssystem einschätzt: Kanäle, Einstellungen, Dublettenbereinigung und Zustellgarantien. Warum aus dem „Versenden einer E-Mail“ still und leise ein sechswöchiges Projekt wird.

So schätzen Sie einen Datei-Upload ein: Größenbeschränkungen, Virenprüfung, Wiederaufnahme der Übertragung, Speicherung und Aufbewahrung. Das Ziehen und Ablegen ist der einfache Teil; die eigentliche Herausforderung liegt dahinter.

So erstellen Sie ein Dashboard: Datenquellen, Aktualisierungshäufigkeit, Zeitzonen, Detailansichten, Berechtigungen. Das Diagramm ist einfach; die dahinterliegende Datenpipeline macht die Arbeit aus.

Wie man einen unzuverlässigen Test einschätzt: Warum es zwei Schätzungen sind und nicht nur eine, und warum eine zeitliche Begrenzung besser ist als ein Streit über Punkte, wenn die Antwort davon abhängt, was Sie herausfinden.

So schätzen Sie einen Fehler ein, der sich nicht reproduzieren lässt: Sie können nicht den Aufwand für die Behebung abschätzen, sondern nur den für die Suche. So legen Sie ein Zeitlimit für die Untersuchung fest, anstatt über eine Story abzustimmen, die niemand einsehen kann.

Wie lässt sich ein Leistungsrückgang einschätzen: Der Großteil der Arbeit besteht in der Diagnose, nicht in der Behebung. Wie lässt sich das Ausmaß einschätzen, wenn die Ursache unbekannt ist und ein SLO auf dem Spiel steht?

Wie man einen vom Kunden gemeldeten Fehler einschätzt: Der im Ticket angegebene Aufwand bestimmt den Umfang. Wie man eine einzeilige Korrektur von einer Lösung unterscheidet, die den gesamten Sprint in Anspruch nimmt.

So schätzen Sie den Aufwand für eine Datenbankmigration ein: Nachvervollständigung, Sperrdauer, Rollout und Rollback. „Eine Spalte hinzufügen“ entspricht einer Zeile SQL; die Schätzung bezieht sich auf die Sekunde.

So schätzen Sie den Aufwand für eine Datenmigration ein: Datenübertragung zwischen Systemen, Abgleich und Umstellung. Die Transformation dauert eine Stunde; die Bereinigung erstreckt sich über ein Quartal.

So schätzen Sie ein Framework-Upgrade ein: Warum eine Erhöhung der Hauptversionsnummer ein Projekt und kein Ticket ist – und wie Sie es in Stories unterteilen, deren Umfang Sie tatsächlich einschätzen können.

So schätzen Sie den Aufwand für ein Dependency-Upgrade ein: Der „Long-Tail“-Effekt, hinter dem sich N Spitzenwerte in einem Ticket verbergen. Lesen Sie zunächst die Changelogs und schätzen Sie dann den Aufwand für das, was Sie gefunden haben.

So schätzen Sie den Aufwand für eine CI/CD-Umstellung ein: Da es für die Pipeline-Arbeiten keine Demo gibt, unterteilen Sie das Projekt in Teile, die gestrichen werden können. Die vierteljährliche Aufgabe, die im Backlog als Refactoring verborgen ist.

So schätzen Sie den Aufwand für den Wechsel zu einer API eines Drittanbieters ein: semantische Lücken, Parallelbetrieb und die Annahmen, die in den Eigenheiten des bisherigen Anbieters verankert sind. Die neue API sieht lediglich identisch aus.

So planen Sie die Einführung einer Ratenbegrenzung: Schwellenwerte, Testphasen, Kundenkommunikation. Die Programmierung dauert einen halben Tag; die Festlegung von Grenzwerten, über die sich niemand beschwert, ist die eigentliche Arbeit.

So schätzen Sie den Aufwand für eine Änderung am Design-System ein: Token-Einführung, Auslaufpfade, Codemod-Abdeckung und die 200 Aufrufstellen, die die alte Komponente verwenden. Schätzen Sie den Umfang der nachgelagerten Auswirkungen ein.

So schätzen Sie den Aufwand für eine Barrierefreiheitskorrektur ein: A11y-Probleme sind Funktionen, die Sie beim ersten Mal nicht implementiert haben. Warum Sie den Umfang der Problemgruppe und nicht den einzelnen Einzelfall einschätzen sollten.

So planen Sie die Einführung eines Feature-Flags: schrittweise Prozentsätze, Kill-Switches, Gating-Kennzahlen und die Aufräumarbeiten, die niemand einplant. Ein Flag ist ein kleines Produkt, kein Deployment.

Wie man einen Forschungs-Spike einschätzt: Ein Spike ist ein zeitlich begrenzter Arbeitsabschnitt mit einem zu erbringenden Ergebnis, keine Story. Wie man verhindert, dass er sich unbemerkt zu der Arbeit entwickelt, für die er ursprünglich vorgesehen war.

Wie man einen Prototyp einschätzt: Es handelt sich um ein Ergebnis, das zum Lernen und nicht zum Einsatz gedacht ist. Wie man verhindert, dass aus dem „Wegwerfprodukt“ der Produktionscode wird, mit dem niemand gerechnet hat.

Wie man ein ML-Experiment einschätzt: Es handelt sich um Forschung mit technischem Bezug. Das Modell ist einfach, die Arbeit liegt in den Daten. Wie man ein Budget festlegt – keine Prognose.