Produktgrundlagen · Gemischt

Von der Spezifikation zu Aufgaben, mit denen man anfangen kann

In einem Satz: Eine gute Aufgabe endet in einem Ergebnis, das man ausführen und prüfen kann, und dauert einen bis zwei Tage — nicht eine Woche und nicht eine Stunde.

Wie man richtig schneidet

Schneiden Sie nach Wert, nicht nach Schicht. „Bildschirm“, „Server“, „Datenbank“ sind drei Aufgaben, von denen keine etwas liefert, bis alle fertig sind. „Der Nutzer kann einen Entwurf speichern“ ist eine Aufgabe, die drei Schichten berührt und in etwas Zeigbarem endet.

Ist eine Aufgabe zu groß, suchen Sie die Varianten: zuerst der Erfolgspfad, Randfälle später; zuerst ein Nutzer, viele später.

Was auf der Karte stehen muss

Kontext in einer Zeile — wer das braucht und warum. Abnahmekriterien in einheitlichem Format. Eine Abhängigkeit, falls vorhanden. Und ein Link zur Spezifikation oder Diskussion, die sie hervorbrachte.

Was nicht drin sein sollte: eine detaillierte Lösung. Diktiert jede Karte die Umsetzung, haben Sie den Grund beseitigt, Entwickler einzustellen.

Zeichen für schlechtes Schneiden

Eine Aufgabe, die zwischen Arbeitszyklen rollt, eine Aufgabe, die drei Tage „fast fertig“ ist, und eine Aufgabe, die man ohne drei andere nicht testen kann. In allen Fällen wurde nach technischer Struktur geschnitten und nicht nach Ergebnis.

Im Detail

Schreiben Sie die Abnahmekriterien, bevor Sie Code schreiben — sie definieren den Test. Eine Aufgabe, für die sich keine Abnahmekriterien formulieren lassen, ist meist verkappte Forschung, und dann ist sie besser als solche definiert: ein zeitlich begrenzter Slot, eine definierte Frage und ein geschriebenes Ergebnis.