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 Ihrem Code, sondern in den Besonderheiten des Identitätsanbieters. Die Fragen, die Sie beantworten 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. Das Gespräch, das geführt werden muss, bevor konkrete Zahlen feststehen.

Wie man eine Suchfunktion einschätzt: Relevanz, Rangfolge, Facettierung und wer für den Index verantwortlich ist. Die Fragen, die aus dem bloßen „Hinzufügen einer Suchleiste“ eine fundierte Einschätzung machen.

Wie man ein Benachrichtigungssystem einschätzt: Kanäle, Einstellungen, Dublettenbereinigung und Zustellgarantien. Warum aus dem einfachen „Versenden einer E-Mail“ unbemerkt 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 Drag-and-Drop ist der einfache Teil; die eigentliche Herausforderung liegt im Hintergrund.

So erstellen Sie ein Dashboard: Datenquellen, Aktualisierungshäufigkeit, Zeitzonen, Detailansichten, Zugriffsrechte. Das Diagramm selbst ist einfach; die dahinterliegende Datenpipeline macht die eigentliche 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 man herausfindet.

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?

So schätzen Sie einen vom Kunden gemeldeten Fehler ein: Der im Ticket angegebene Aufwand bestimmt den Umfang. So unterscheiden Sie zwischen einer einzeiligen Korrektur und einer Lösung, 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 dauert 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“-Anstieg, 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 danach, was gestrichen werden kann. Das vierteljährliche Projekt, das sich im Backlog als Refactoring verbirgt.

Wie man den Wechsel zu einer API eines Drittanbieters einschätzt: 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 schrittweise 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 einer Änderung am Design-System ein: Token-Einführung, Auslaufpfade, Codemod-Abdeckung und die 200 Aufrufstellen, die die alte Komponente verwenden. Bewerten Sie den Umfang der nachgelagerten Auswirkungen.

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

So planen Sie die Einführung eines Feature-Flags: stufenweise 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 Ergebnis, keine Story. Wie lässt sich verhindern, dass er still und leise zu dem Arbeitsumfang wird, für den 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, die mit technischer Umsetzung verbunden ist. Das Modell ist einfach, die Arbeit liegt in den Daten. Wie man ein Budget bemisst – keine Prognose.