Grundlagen der Aufwandsschätzung

Aufwandsschätzung bedeutet nicht, die Zukunft exakt vorherzusagen. Du beschreibst, wie groß eine Aufgabe voraussichtlich ist, welche Annahmen dahinterstehen und welche Unsicherheiten noch geklärt werden müssen. Gerade in Android-Projekten ist das wichtig, weil eine scheinbar kleine UI-Änderung schnell Architektur, Coroutines, Tests, Geräteverhalten, Barrierefreiheit und Release-Qualität berühren kann.

Was ist das?

Estimation Basics sind die Grundlagen, mit denen du Entwicklungsarbeit realistisch einschätzt. Du zerlegst eine Anforderung in kleinere Teile, erkennst offene Fragen und benennst Risiken. Eine gute Schätzung ist daher mehr als eine Zahl wie „zwei Tage“. Sie sagt auch: „Das ist zwei Tage Arbeit, wenn die API stabil ist, keine Offline-Unterstützung nötig ist und vorhandene Tests weiterlaufen.“

Für Anfänger ist das wichtigste mentale Modell: Schätzen heißt nicht raten, sondern sortieren. Du sortierst bekannten Scope, unbekannte Details und mögliche Risiken. Scope beschreibt, was wirklich geliefert werden soll. Unsicherheit beschreibt, was du noch nicht weißt. Risiko beschreibt, was den Plan ernsthaft verändern kann, wenn es anders ausfällt als erwartet.

Im Android-Kontext tauchen diese Punkte ständig auf. Ein neues Compose-Screen wirkt überschaubar, bis du klären musst, ob Daten aus einem ViewModel kommen, ob Flow verwendet wird, ob Ladezustände abgedeckt sind, ob Navigation angepasst werden muss und ob Tests in der CI laufen. Eine Schätzung ohne diese Fragen ist schwach, weil sie die eigentliche Arbeit versteckt.

Das Ziel ist nicht, jede Aufgabe perfekt vorab zu verstehen. Das wäre oft zu teuer. Ziel ist, früh sichtbar zu machen, wo du sicher bist und wo du noch lernen musst. Damit hilfst du dir selbst, deinem Team und Produktverantwortlichen. Alle können besser entscheiden, ob eine Aufgabe sofort gebaut, zuerst geschnitten oder durch einen kleinen technischen Spike vorbereitet werden sollte.

Wie funktioniert es?

Du beginnst mit der Anforderung und formulierst sie als sichtbares Ergebnis. Nicht: „Login verbessern“. Besser: „Der Login zeigt einen Ladezustand, behandelt Netzwerkfehler und speichert den erfolgreichen Session-Status.“ Dadurch wird Scope greifbar. Danach zerlegst du das Ergebnis in Arbeitspakete: UI, State, Datenquelle, Fehlerbehandlung, Tests, Review und Integration.

Als Nächstes markierst du Unsicherheiten. Bei Android sind typische Fragen: Gibt es bereits eine Repository-Schicht? Wird die Funktion mit Coroutines oder Flow umgesetzt? Muss ein bestehender Screen migriert werden? Gibt es Design-Vorgaben für Compose? Welche API-Fehler können auftreten? Welche Geräte- oder Versionsunterschiede sind relevant? Muss das Verhalten durch instrumentierte Tests geprüft werden oder reichen lokale Unit-Tests?

Risiko entsteht dort, wo Unsicherheit teuer werden kann. Ein unbekannter Endpoint ist ein Risiko, wenn die UI stark von seiner Datenstruktur abhängt. Ein neues Coroutine-Verhalten ist ein Risiko, wenn Cancellation, Dispatcher oder Lifecycle falsch verwendet werden könnten. Fehlende Tests sind ein Risiko, wenn eine Änderung in der Release-Pipeline erst spät auffällt. Android-Qualität ist nicht nur ein Thema am Ende, sondern beeinflusst bereits die Schätzung.

Eine einfache Regel hilft: Schätze kleine, überprüfbare Schritte statt große Blöcke. Wenn ein Task mehr als wenige klare Arbeitspakete enthält, ist er wahrscheinlich zu groß. Zerlege ihn so, dass jedes Teil ein beobachtbares Ergebnis hat. „Fehlerzustand im Login anzeigen“ ist besser schätzbar als „Login fertig machen“. „Repository-Methode mit Fake im Unit-Test abdecken“ ist besser schätzbar als „Tests schreiben“.

Du solltest außerdem Annahmen dokumentieren. Eine Schätzung ohne Annahmen klingt präziser, als sie ist. Schreibe kurz dazu, worauf deine Zahl basiert: vorhandene Architektur, bekannte API, bestehende Testinfrastruktur, kein neues Design-System, keine Offline-Anforderung. Wenn eine Annahme später falsch ist, ist die Schätzung nicht automatisch schlecht. Sie war nur an eine Bedingung gebunden, die sich geändert hat.

Für Juniors ist noch ein Punkt wichtig: Vergiss Review, Testzeit und Integration nicht. Reine Implementierungszeit ist nur ein Teil der Arbeit. In echten Android-Projekten musst du prüfen, ob Compose-State stabil bleibt, ob Coroutine-Jobs nicht aus dem falschen Scope gestartet werden, ob Tests reproduzierbar laufen und ob CI-Feedback berücksichtigt wird. Diese Arbeit gehört zur Schätzung, weil sie zur Lieferung gehört.

In der Praxis

Stell dir vor, du sollst in einer bestehenden Android-App einen Profil-Screen um eine „Daten aktualisieren“-Aktion erweitern. Die App nutzt Kotlin, Jetpack Compose, ViewModel, Coroutines und ein Repository. Eine schwache Schätzung wäre: „Button einbauen, ein halber Tag.“ Das ignoriert Scope und Risiko. Eine bessere Schätzung beginnt mit einer Zerlegung:

• Compose-Button und Ladezustand anzeigen
• ViewModel-Event für Aktualisierung ergänzen
• Repository-Methode aufrufen
• Erfolg und Fehler im UI-State abbilden
• Unit-Test für State-Übergänge schreiben
• Manuell prüfen, ob Rotation oder erneutes Öffnen des Screens kein doppeltes Laden auslöst
• CI-Testlauf beobachten

Ein kleiner Beispielausschnitt zeigt, warum die Aufgabe mehr als nur UI ist:

data class ProfileUiState(
    val isRefreshing: Boolean = false,
    val errorMessage: String? = null
)

class ProfileViewModel(
    private val repository: ProfileRepository
) : ViewModel() {

    private val _uiState = MutableStateFlow(ProfileUiState())
    val uiState: StateFlow<ProfileUiState> = _uiState.asStateFlow()

    fun refreshProfile() {
        viewModelScope.launch {
            _uiState.update { it.copy(isRefreshing = true, errorMessage = null) }

            runCatching {
                repository.refreshProfile()
            }.onFailure {
                _uiState.update {
                    it.copy(
                        isRefreshing = false,
                        errorMessage = "Profil konnte nicht aktualisiert werden."
                    )
                }
            }.onSuccess {
                _uiState.update { it.copy(isRefreshing = false) }
            }
        }
    }
}

Beim Schätzen erkennst du hier mehrere Fragen. Ist repository.refreshProfile() bereits vorhanden? Läuft es auf einem passenden Dispatcher oder muss die Repository-Schicht das sicherstellen? Gibt es ein definiertes Fehlerformat? Soll der Button während des Ladens deaktiviert werden? Muss ein Snackbar-Event verwendet werden oder reicht ein Text im Screen? Soll ein fehlgeschlagener Versuch erneut gestartet werden können?

Eine konkrete Entscheidungsregel: Wenn du bei einer Aufgabe mehr als drei fachliche oder technische offene Fragen findest, plane zuerst eine kurze Klärung oder einen Spike ein. Ein Spike ist ein begrenztes Lernpaket, zum Beispiel „Repository-API prüfen und minimalen Refresh-Aufruf gegen Fake testen“. Er liefert keine vollständige Funktion, reduziert aber Unsicherheit. Danach kannst du die eigentliche Umsetzung genauer schätzen.

Eine typische Stolperfalle ist, nur den glücklichen Pfad zu schätzen. Der Button funktioniert bei stabiler Verbindung, also wirkt die Aufgabe erledigt. In der Praxis fehlen dann Fehlerzustand, Ladezustand, Testbarkeit, Coroutine-Cancellation oder ein sauberer Umgang mit mehrfachen Klicks. Genau diese Punkte verursachen später Nacharbeit. Deshalb solltest du in deiner Schätzung mindestens Erfolg, Fehler, Wartezustand und Teststrategie prüfen.

Eine zweite Stolperfalle ist zu großer Scope. „Profilbereich verbessern“ kann Avatar, Name, Validierung, Refresh, Navigation, Cache, Analytics und Fehlertexte enthalten. Das lässt sich kaum sinnvoll schätzen. Schneide den Scope in Ergebnisse, die einzeln reviewbar sind. Ein Pull Request für den Refresh-Button ist überschaubarer als ein großer Umbau des gesamten Profilbereichs. Kleinere Änderungen senken Risiko, machen Code-Reviews klarer und geben schneller Feedback aus Tests und CI.

Für die Praxis kannst du eine einfache Schätzvorlage verwenden:

Schätznotiz

• Ergebnis: Was sieht oder kann der Nutzer danach?
• Scope: Welche Dateien, Schichten oder Screens sind betroffen?
• Annahmen: Was muss bereits vorhanden oder stabil sein?
• Unsicherheiten: Welche Fragen sind offen?
• Risiken: Was könnte die Arbeit deutlich vergrößern?
• Validierung: Welche Tests, Debug-Schritte oder Reviews zeigen, dass es funktioniert?

Für das Profil-Beispiel könnte deine Notiz so aussehen: „Refresh-Aktion im Profil-Screen mit Lade- und Fehlerzustand. Betroffen sind Compose-Screen, ProfileViewModel, Repository und ViewModel-Tests. Annahme: Repository hat bereits eine refresh-Methode oder kann ohne API-Änderung ergänzt werden. Unsicherheit: Fehlerdarstellung im Design ist nicht geklärt. Risiko: Mehrfachklicks und Lifecycle können doppelte Requests auslösen. Validierung: Unit-Test für State-Übergänge, manueller Test mit Fake-Fehler, CI-Lauf.“

Diese Notiz ist nicht lang, aber sie macht die Schätzung belastbarer. Sie zeigt, dass du Android-Arbeit nicht nur als Tippen von Code betrachtest, sondern als Lieferung eines überprüfbaren Verhaltens. Genau das unterscheidet eine grobe Vermutung von einer professionellen Einschätzung.

Fazit

Gute Aufwandsschätzung beginnt damit, Unsicherheit sichtbar zu machen und Scope bewusst zu schneiden. Du musst nicht jede Android-API im Detail kennen, um besser zu schätzen. Du brauchst ein klares Ergebnis, kleine Arbeitspakete, ehrliche Annahmen und einen Blick für Risiken wie fehlende Tests, unklare Coroutine-Nutzung oder späte CI-Probleme. Übe das an deinem nächsten Task: Schreibe vor dem Coden eine kurze Schätznotiz, baue die kleinste prüfbare Änderung, teste den kritischen Pfad und lass im Code-Review prüfen, ob deine Annahmen wirklich gehalten haben.