Home > Beratung, Entwicklung, Projektmanagement > Scrum (4) – Anforderungen formulieren

Scrum (4) – Anforderungen formulieren

Die Anforderungsermittlung in Scrum erfolgt nach einer einfachen und pragmatischen Vorgehensweise

  1. Es gibt eine Produktidee
  2. Ein Produktkonzept wird erstellt
  3. Das Product Backlog wird aufgefüllt und priorisiert

Produktkonzept

Das Produktkonzept ist eine gemeinsame Grundlage aller Produkt-/Projektbeteiligten und entscheidet über die Durchführung des Projektes. Es formuliert den Mehrwert für den Endkunden (idealerweise anhand konkreter Beispiele) UND den Mehrwert für die entwickelnde Firma.

Wichtig ist, das bereits die wichtigsten Eigenschaften des Produkts beschrieben werden (ca. drei). Diese bestimmen die Richtung der Produktentwicklung und sollen es von der Konkurrenz abheben.  Es sollten wirklich nur die wichtigsten Produkteigenschaften im Produktkonzept stehen, was oft schwieriger ist als große Konzepte zu schreiben. Es sollte kurz und knapp gehalten werden und leicht verständlich sein (1-2 Seiten).

Das Produktkonzept wird von Product Owner, Interessenvertretern und Team erstellt. Die Ersteller des Produktkonzeptes sollten auch im fortlaufenden Projekt involviert sein um Kontinuität und Wissensverlust zu vermeiden.

Product Backlog

Das Product Backlog sollte alle wesentlichen, für den Einsatz der Software erforderlichen Anforderungen enthalten.

Zu den Anforderungen können sowohl funktionale als auch nicht funktionale Anforderungen (z. B. Skalierbarkeit oder User Interface) gehören.

Um die Menge an Anforderungen übersichtlich zu halten, sollten die einzelnen Anforderungen entsprechend ihrer Priorität detailliert werden. Der Fokus wird stets auf die wichtigsten Anforderungen und Features gelenkt. Sofern notwendig gibt es zu einzelnen Anforderungen Anforderungsworkshops.

    Anforderungen sollten INVEST-Merkmale besitzen:

    • Independent
    • Negotiable
    • Valuable
    • Estimatable
    • Small
    • Testable

    Abfolge

      1. Zunächst wird ein Thema festgelegt (z. B. Tagging)
      2. Zu diesem Thema gibt es zunächst EINE User Story
      3. User Stories werden im Laufe der Zeit in mehrere detaillierte Geschichten aufgeteilt (spätestens vor der Sprint-Planungssitzung)
      4. Jede User Story muss Akzeptanzkriterien besitzen
      5. Einzelne Anforderungen werden in einer Sprint-Planungssitzung ausgewählt und im Sprint umgesetzt und getestet

        User Stories

        User Stories beschreiben Anforderungen aus der Sicht des Endanwenders.
        Eine User Story besteht aus einem Titel, einer kurzen textuellen
        Beschreibung der Anforderung und Akzeptanzkriterien.
        User Stories sollten jeweils auf eine Karteikarte passen und die
        INVEST-Kriterien erfüllen.

        Name bzw. Titel

        Der Name bzw. Titel der User Story sollte eine Tätigkeit darstellen

        Beispiel:
        Seiten im Portal taggen

        Beschreibung

        Die textuelle Beschreibung sollte eine Benutzerrolle, das Ziel und optional den Nutzen des Merkmals beinhalten. Die Benutzerrolle profitiert von dem Merkmal.

        Beispiel:
        Als Basisanwender möchte ich Seiten im Portal mit Tags versehen, um diese schnell wiederfinden zu können.

        Akzeptanzkriterien

        Die Akzeptanzkriterien legen fest, ab wann eine User Story akzeptiert werden kann.

        Beispiel:

        • Eine Seite im Portal kann vom Nutzer mit Tags versehen werden.
        • Die Tags können nachträglich editiert werden.

        Akzeptanzkriterien können in Akzeptanztests umgewandelt werden.

        Grenzen von User Stories

        Anforderungen an Design oder auch bestimmte Subkomponenten können normalerweise nicht in User Stories beschrieben werden. Hierfür gibt es dann User Interface Spezifikationen oder auch UML-Diagramme.

        blog comments powered by Disqus
        1. Bisher keine Kommentare
        1. Bisher keine Trackbacks
        Du musst Dich anmelden um einen Kommentar zu schreiben

        Switch to our mobile site