Benutzer:Oemmler/INVEST

Das Akronym INVEST wurde von Bill Wake als Eselsbrücke zur Erinnerung an die Qualitätseigenschaften einer guten User Story, wie diese in Scrum verwendet wird, erfunden.

Buchstabe	Bedeutung(Übersetzung)	Beschreibung
I	Independent (Unabhängig)	Die User Story sollte in sich geschlossen sein und keine Abhängigkeit von einem anderen User Story besitzen.
N	Negotiable (Verhandelbar)	Die User Story kann immer wieder verhandelt werden, solange sie noch nicht Teil einer Iteration ist.
V	Valuable (Wertvoll)	Die User Story besitzt einen Mehrwert für den Endkunden.
E	Estimable (Schätzbar)	Die User Story kann in ihrer Größe abgeschätzt werden.
S	Sized oder Small (Angemessen oder klein)	Eine User Story sollte nicht so groß sein, dass es unmöglich ist sie zu planen oder in einem überschaubaren Zeitraum umzusetzen.
T	Testable (Testbar)	Die User Story und die dazugehörigen Anforderungen müssen durch Prüfmethoden testbar sein.

Independent (Unabhängig)

Eines der Merkmale der Agile Methoden wie Scrum oder XP ist die Fähigkeit eine User Story, unter Berücksichtigung ihrer relativen Priorität ohne viel Aufwand, zu bewegen.

Negotiable (Verhandelbar)

Das Einzige, was in agilen Projketen fest und in Stein gemeißelt ist, ist das Sprint Backlog und auch dieses kann verändert werden. Solange eine User Story in Product Backlog liegt kann sie in Abhängigkeit von Änderungen des Geschäfts, Markts oder technischen Rahmenbedingungen umgeschrieben oder sogar verworfen werden.

Valuable (Wertvoll)

Der Fokus User Story liegt immer auf dem aktuellen, projektbezogenen Wert für den Endkunden des Produktes. Eine technische User Story verstößt damit gegen die Agilen Prinzipien des agilen Manifestes.

Estimable (Schätzbar)

Wenn ein User Story Größe nicht geschätzt werden kann, wird es nie geplant, beauftragt werden, und damit zu einem Teil einer Iteration. So gibt es eigentlich keinen Sinn, halten diese Art von User Story im Product Backlog überhaupt. Meistens kann Schätzung nicht aufgrund des Fehlens von unterstützenden Informationen entweder in der Geschichte Beschreibung selbst oder direkt aus dem Produkt Halter erfolgen.

Sized oder Small (Angemessen oder klein)

Versuchen Sie, die User Story so klein zu halten, dass sie nur wenige Personentage höchsten ein paar Personenwochen in Anspruch nimmt. Alles, was jenseits dieser Größe ist, sollte als zu groß erachten werden um es mit einem ausreichenden Maß an Sicherheit abschätzen zu können. Es sollte als "Epic" betrachtet und in kleinere User Stories heruntergebrochen werden. Es ist unproblematisch mit Epics zu arbeiten, solange diese heruntergebrochen werden, wenn sie in eine Iteration eingeplant sind.

Testable (Testbar)

Beachten Sie, dass eine User Story nur dann als erledigt betrachtet werden sollte, wenn diese erfolgreich getestet wurde. Wenn man eine Story aus Mangel an Informationen nicht testen kann, sollte diese nicht als Kandidat für einen Sprint Backlog in Betracht gezogen werden.

Einzelnachweise

The INVEST mnemonic was created by Bill Wake as a reminder of the characteristics of a good quality user story, as may be used in a Scrum backlog or XP project.

Letter	Meaning	Description
I	Independent	The user story should be self-contained, in a way that there is no inherent dependency on another user story.
N	Negotiable	User stories, up until they are part of an iteration, can always be changed and rewritten.
V	Valuable	A user story must deliver value to the end user.
E	Estimate-able	You must always be able to estimate the size of a user story.
S	Sized appropriately or Small	User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
T	Testable	The user story or its related description must provide the necessary information to make test development possible.

Independent

One of the characteristics of Agile Methodologies such as Scrum or XP is the ability to move stories around, taking into account their relative priority - for example - without much effort. If you find user stories that are tightly dependent, a good idea might be to combine them into a single user story.

Negotiable

The only thing that is fixed and set in stone in an agile project is an iteration backlog (and, even then, it can be broken). While the story lies in the product backlog, it can be rewritten or even discarded, depending on business, market, technical or any other type of requirement by team members.

Valuable

The focus here is to bring actual project-related value to the end-user. Coming up with technical stories that are really fun to code but bring no value to the end-user violates one of the Agile Principles, which is to continuously deliver valuable software.

Estimate-able

If a user story size cannot be estimated, it will never be planned, tasked, and, thus, become part of an iteration. So there's actually no point in keeping this kind of user story in the Product Backlog at all. Most of the time, estimation cannot be executed due to the lack of supporting information either in the story description itself or directly from the Product Owner.

Sized appropriately or Small

Try to keep your user story sizes to typically a few person-days and at most a few person-weeks. Anything beyond that range should be considered too large to be estimated with a good level of certainty or even "epic" and broken down into smaller user stories. There's no problem in starting with epic stories, as long as they are broken down when the time to place them in an iteration backlog becomes closer.

Testable

Bear in mind that a story should only be considered DONE, among other things, if it was tested successfully. If one cannot test a story due to lack of information (see "Estimate-able" above), the story should not be considered a good candidate to be part of an iteration Backlog. This is especially true for teams employing TDD - Test Driven Development

External links

1. Jeff Sutherland's Blog

References

Category:Software development process