t2informatik » Wissen kompakt » Definition of Ready

Definition of Ready

Eine Liste von Kriterien für Backlog Items

Die Definition of Ready – auch als DoR abgekürzt – ist eine Liste von Kriterien, die Backlog Items erfüllen müssen, bevor sie in einen Sprint als User Storys eingeplant werden können. Beispiele für eine Definition of Ready:

  • Das Backlog Item ist geschätzt und klein genug, dass es in einem Sprint umgesetzt werden kann.
  • Das Backlog Item hat mindestens ein Akzeptanzkriterium.
  • Das Backlog Item und die Akzeptanzkriterien werden von allen Beteiligten verstanden.
  • Mögliche externe Abhängigkeiten des Backlog Items sind beseitigt.

Bekannt ist die Aussage von Jeff Sutherland, dem Mitbegründer von Scrum: „READY is when the team says: ‚Ah, we get it‘.“ Nur wenn ein Backlog Item im Status „Ready“ ist, darf es in einen Sprint aufgenommen werden.

Definition of Ready - Wissen kompakt - t2informatik

Im Gegensatz zur Definiton of Done, bei der das Entwicklungsteam für die Einhaltung der Kriterien verantwortlich ist, ist bei der Definition of Ready der Product Owner verantwortlich. Die Idee ist, dass nur Backlog Items in den Sprint gelangen, die der DoR entsprechen. In diesem Zusammenhang wird manchmal auch von den Conditions of Satisfaction gesprochen.

Im Allgemeinen ist eine Definition of Ready ein sinnvolles Werkzeug, denn es sorgt für Klarheit und Transparenz und erhöht das Verständnis der Beteiligten. Wichtige Informationen werden dokumentiert und Probleme vermieden, bevor sie entstehen. Eine User Story, die bspw. externe Abhängigkeiten aufweist, könnte das Sprint-Ziel gefährden. Im Speziellen sollten Organisationen jedoch bei der Verwendung einer Definition of Ready darauf achten, dass sie nicht zu rigeros formuliert wird und so die Entwicklung behindert. Eine DoR, die bspw. fordert: „Zu jeder User Story, die sich auf Screens bezieht, muss es fertige Mock-Objekte geben“ wäre eine solche – möglicherweise unnötige – Einschränkung. Besser wäre es „Zu jeder User Story, die sich auf wichtige Screens bezieht, sollte es in ausreichendem Maße Mock-Objekte geben, damit das Team Unklarheiten im laufenden Sprint klären kann.“ Somit wären entsprechende Vorbedingungen dokumentiert, das Entwicklungsteam könnte aber an der Realisierung der User Story arbeiten.

“Das Fachwissen zu Softwarearchitekturen, die Expertise in der Softwareentwicklung und die sehr flexible Arbeitsweise waren ideal für uns.“
„Ich brauche Freiheit und Vertrauen. Und ich möchte Verantwortung übernehmen und dabei Spaß haben!“
Share This