Checkliste User Stories

Kennen Sie die Situation von unklaren User Stories an einem Sprint Planning Meeting oder zu Beginn eines Sprints? Oft sind Anforderungen nicht messbar definiert, nicht funktionale Anforderungen fehlen komplett, Stories sind riesig oder haben keinen Business Value (z.B. nur GUI erstellen als Story).

Eine Möglichkeit um solche Probleme zu minimieren ist eine „Definition of Ready“, welche das Team für sich definiert. Neben der Wichtigkeit, dass jedes Teammitglied den Inhalt der Stories kennt und es ein gemeinsames Verständnis dafür gibt, können Checklisten zusätzlich helfen.

Eine mögliche Checkliste könnte wie folgt aussehen:

Story-Text

• Ist klar wer der Akteur ist?
• Ist klar auf welchem Dialog welche Aktion ausgeführt wird? Oder wenn das System etwas macht was der Auslöser ist?
• Ist klar was die neue Funktion macht, wenn sie ausgeführt wird?
• Ist ein Nutzen gegeben wieso die Funktion benötigt wird?
• Ist die Story vertikal? -> sie muss vertikal sein
• Sind alle Wörter klar definiert? (Wörter wie korrekt, wie vorher, etc. dürfen nicht vorkommen)
• Können die Fragen „Wer? Wo? Was?“ beantwortet werden?
• Gibt es keine Unklarheiten die noch abgeklärt werden müssen?
• Gibt es Vorbedinungen oder andere Stories die erfüllt sein müssen, damit die Story umsetzbar ist?
• Gibt es Annahmen für die Schätzung? Wenn ja welche?

Mögliches Template

Als [User/Rolle] möchte ich, dass die [Funktion] ausgeführt wird, wenn ich die [Aktion] auslöse, so dass [Grund] erfüllt wird.

Akzeptanz Kriterien

• Ist das Kriterium messbar?
• Könnte aus dem Kriterum ein Messbarer Test (Integration /Systemtest oder manueller Test) gemacht werden (Es muss möglich sein einen TestCase zu definieren)?
• Sind Kriterien vorhanden, die ein User überprüfen kann (z.B. ist ein Wert im UI eingetragen, ist der Wert in der Datenbank? Ect.)
• Betrifft das Kriterium einzig und allein die neue Funktion?
• Gibt es allenfalls messbare Performance Anforderungen wenn ja welche?
• Gibt es Security Anforderungen wenn ja welche?
• Sind alle nicht funktionalen Anforderungen enthalten?
• Können die Fragen Was? und Wie? Beantwortet werden?
• Sind mehr als 7 Akzeptanz Kriterien vorhanden? Wenn ja könnte das ein Indiz sein, dass die Story zu gross ist.

Benutzerrollen

Benutzerrollen sollten für ein Projekt spezifisch definiert werden. Dabei kann eine Eigenschaft mit einem Namen verknüpft werden. Ein Beispiel für eine Web Applikation, mit den Rollen: Admin, Moderator, Writer und Reader. Im Backend gibt’s die Rolle Administrator.

User Story Texte können demnach wie folgt beginnen:

Als Portal Rudi möchte ich, dass … , Als Backend Albert möchte ich, dass …

INVEST und SMART

Weiter können beim Thema Stories und Tasks schreiben die Prinzipien von INVEST und SMART weiter helfen. (Quelle: xp123)

INVEST

Independent

Stories are easiest to work with if they are independent. That is, we’d like them to not overlap in concept, and we’d like to be able to schedule and implement them in any order. We can’t always achieve this; once in a while we may say things like “3 points for the first report, then 1 point for each of the others.”

Negotiable … and Negotiated

A good story is negotiable. It is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details. Over time, the card may acquire notes, test ideas, and so on, but we don’t need these to prioritize or schedule stories.

Valuable

A story needs to be valuable. We don’t care about value to just anybody; it needs to be valuable to the customer. Developers may have (legitimate) concerns, but these framed in a way that makes the customer perceive them as important. This is especially an issue when splitting stories. Think of a whole story as a multi-layer cake, e.g., a network layer, a persistence layer, a logic layer, and a presentation layer. When we split a story, we’re serving up only part of that cake. We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers. Developers often have an inclination to work on only one layer at a time (and get it “right”); but a full database layer (for example) has little value to the customer if there’s no presentation layer.

Making each slice valuable to the customer supports XP’s pay-as-you-go attitude toward infrastructure.

Estimable

A good story can be estimated. We don’t need an exact estimate, but just enough to help the customer rank and schedule the story’s implementation. Being estimable is partly a function of being negotiated, as it’s hard to estimate a story we don’t understand. It is also a function of size: bigger stories are harder to estimate. Finally, it’s a function of the team: what’s easy to estimate will vary depending on the team’s experience. (Sometimes a team may have to split a story into a (time-boxed) “spike” that will give the team enough information to make a decent estimate, and the rest of the story that will actually implement the desired feature.)

Small

Good stories tend to be small. Stories typically represent at most a few person-weeks worth of work. (Some teams restrict them to a few person-days of work.) Above this size, and it seems to be too hard to know what’s in the story’s scope. Saying, “it would take me more than a month” often implicitly adds, “as I don’t understand what-all it would entail.” Smaller stories tend to get more accurate estimates.

Story descriptions can be small too (and putting them on an index card helps make that happen). Alistair Cockburn described the cards as tokens promising a future conversation. Remember, the details can be elaborated through conversations with the customer.

Testable

A good story is testable. Writing a story card carries an implicit promise: “I understand what I want well enough that I could write a test for it.” Several teams have reported that by requiring customer tests before implementing a story, the team is more productive. “Testability” has always been a characteristic of good requirements; actually writing the tests early helps us know whether this goal is met.

If a customer doesn’t know how to test something, this may indicate that the story isn’t clear enough, or that it doesn’t reflect something valuable to them, or that the customer just needs help in testing.

SMART Tasks

There is an acronym for creating effective goals: “SMART” –

(There are a lot of variations in what the letters stand for.) These are good characteristics for tasks as well.

Specific

A task needs to be specific enough that everyone can understand what’s involved in it. This helps keep other tasks from overlapping, and helps people understand whether the tasks add up to the full story.

Measurable

The key measure is, “can we mark it as done?” The team needs to agree on what that means, but it should include “does what it is intended to,” “tests are included,” and “the code has been refactored.”

Achievable

The task owner should expect to be able to achieve a task. XP teams have a rule that anybody can ask for help whenever they need it; this certainly includes ensuring that task owners are up to the job.

Relevant

Every task should be relevant, contributing to the story at hand. Stories are broken into tasks for the benefit of developers, but a customer should still be able to expect that every task can be explained and justified.

Time-Boxed

A task should be time-boxed: limited to a specific duration. This doesn’t need to be a formal estimate in hours or days, but there should be an expectation so people know when they should seek help. If a task is harder than expected, the team needs to know it must split the task, change players, or do something to help the task (and story) get done.