Schreiben Benutzergeschichten für interne technische Aufgaben [geschlossen]

Question

Ich versuche, meine Projekte ein wenig besser zu verwalten, so zu versuchen, ich bin auf der Suche einig (schließlich alle) die Eigenschaften von gedränge .

Mit Blick auf User Storys speziell das hohe Niveau Format scheint zu sein:

Als Benutzer Ich kann Funktion Beschreibung

oder

Artifact ist etwas zu tun,

Wie würde ich schreiben "Upgrade der Datenbank"?

Ist es einfach die Datenbank-Upgrade?

Ich glaube, ich bin zu werden abgeworfen, da es kein spezifischer Akteur / Kunde und der Kunde ist die IT-Abteilung.

Answer 1

AS A [person/role]
I NEED TO [do something] 
SO THAT [provides business value]. 

Für Ihr Beispiel einer User Story könnte wie folgt aussehen:

AS A user of the XYZ application
I NEED TO get reports of ABC faster
SO THAT we can increase our conversion rates.
ACCEPTANCE CRITERIA - The database reliably completes transactions on average in 2 seconds.

Ich habe da eine Akzeptanzkriterien hinzugefügt, ohne dass dies werden Sie nie wissen, wann die Arbeit erledigt ist. An diesem Punkt haben Sie einen Business Case für die Datenbank zu aktualisieren. Diese Geschichte würde in eine Geschichte zerlegt werden, wo die Rolle der IT-Abteilung oder DBA, etwa so:

AS AN administrator for the database server
I NEED TO upgrade to the latest version of FancyDB 11.7
SO THAT we can improve the average transaction time for XYZ users to 2 seconds.
ACCEPTANCE CRITERIA - the new version starts successfully, the XYZ developers sign off on the test installation of 11.7, data migration is successful, we have cut over to the new db

Wenn Geschichte Zersetzung zu Ihrem Werkzeugkasten hinzugefügt wird, muss die Geschichte aus starten, wo der Benutzer ein echter Teil des Geschäfts ist, und die „so dass“ führt zu einem echten Mehrwert. Dann zerfallen die Geschichte in eine oder mehr Geschichten, in denen internen Benutzer Dinge tun „so dass“ echte Benutzer die Vorteile in Not erhalten.

Hier sind ein paar Artikel, die über Geschichte Zersetzung sprechen:

http://jpattonassociates.com/the_shrinking_story/

http://old.cognitive-edge.com/wp-content/uploads/1999/11/56-1999-11-Paradox-of-Story.pdf

Answer 2

Scrum ist nicht sehr normativ und es ist nichts in Scrum, die Sie User Stories für Product Backlog Artikel (PBI) verwenden zwingt. Sie können auf jeden Fall Scrum tun, ohne Anforderungen / Funktionen wie Benutzergeschichten zu erfassen, User Stories sind nur eine Möglichkeit, es zu tun. Eigentlich arbeiten Geschichten für viele Teams, vor allem Web-Entwicklungs-Teams, aber das bedeutet nicht, dass sie in allen Fällen funktionieren und bei jedem Projekt (viele Projekte Web-Entwicklung sind, aber nicht alle, wie in Ihrem Fall). Es gibt keinen Konsens über Geschichten mit.

Das heißt, die empfohlene Vorlage für User Stories ist eigentlich Als , ich will , so dass . Damit meine ich nicht wählerisch, aber sein, wenn Sie Geschichten verwenden, würde ich wärmstens es vorschlagen, wie es ist zu verwenden, ohne irgendeinen Teil zu entfernen. Zuerst eine Rolle mit tun Hilfe (a gleichen Benutzer / Person kann mehrere Rollen haben) Geschichten zu entdecken. Dann Angabe der Vorteile ist wirklich wichtig, den Geschäftswert einer Geschichte auszusetzen, um sie gut zu priorisieren. den Wert betrifft, sollten Sie daran denken, wie Endbenutzer / Kunden ( „ Kundenbrille setzen auf “ --Mary Poppendieck). Es ist wirklich nicht immer einfach, die Vorteile zum Ausdruck bringen, aber einige Werkzeuge helfen könnte und meine bevorzugte ist die 5 whys (die für die Ursachenanalyse verwendet wird).

In Ihrem Fall könnte dies zu etwas führen wie: Wie die IT-Abteilung, ich mag die Datenbank aktualisiert werden, so dass Benutzer profitieren von den neuesten Funktionen der Anwendung und [eine bessere Arbeit | hat eine bessere Benutzererfahrung ] (wenn auch nicht sehr befriedigend, verwenden Sie die 5 whys).

Aber persönlich finde ich nicht, dass die User Stories sind das beste Medium für technische Aufgaben, auch wenn es klar ist

Aktualisieren der Datenbank eine der bei der Umsetzung eine andere Geschichte beteiligt Aufgaben sein, die direkten Wert für den Benutzer bringt, zum Beispiel ich als Benutzer einen neuen foo zu meiner Bar hinzufügen .

Wenn das Hinzufügen einer foo a bar erfordert eine Datenbank hinter den Kulissen aktualisieren, dann würden Sie diese Arbeit gehören in diese User Story zu implementieren.

Benutzer Geschichten formuliert werden auf diese Weise sicherzustellen, dass jede Arbeit direkt den Endverbraucher in irgendeiner Weise zugute kommt.

Dies wird in den Vordergrund, warum sind User Storys so groß.

Welchen Nutzen der Aktualisierung der Datenbank für den Endbenutzer geben? Keiner? Dann verbringen Sie nicht über die Zeit und Geld, um es zu tun. Verbringen Sie die Zeit und Geld bieten etwas, das den Wert Ihrer Endbenutzer geben wird.

Ist dies der Fall? Dann denken Sie über es andersrum. Vielleicht können Sie nur eine neue Funktion implementieren, wenn Sie die Version x Ihrer Datenbank-Software? In der Abhängigkeit der Geschichte, könnten Sie dieses Datenbank-Upgrade erwähnen erforderlich, um diese Funktion zu liefern.

tl; dr Sie nicht nur im Interesse der es aktualisieren. Stellen Sie sicher, Upgrade fügt greifbaren Mehrwert für Ihre Kunden.

Im Allgemeinen technische Aufgaben in der PB sind verpönt, weil sie sehr selten direkt liefert Mehrwert für die Kunden. Deshalb User Stories sind beliebt, weil sie Sie zwingen, um den Geschäftswert der Geschichte zu denken, und haben sie geliefert hat wird.

Also, warum aktualisieren Sie die Datenbank? Können Sie Geschäftswert in der Aktualisierung es, und warum sollte der Product Owner stimmen Sie lassen die Datenbank aktualisieren, anstatt den Bau neuer Funktionen identifizieren?

Ist es wegen einer neuen Funktion, die es ermöglichen wird, oder macht es einfacher, etwas in Ihrer Anwendung zu tun? In diesem Fall soll, dass etwas das PB-Element sein, und das Datenbank-Upgrade sollte eine Aufgabe innerhalb dieser Geschichte sein. Wenn Sie bereits Geschichten auf der PB haben, die von dem Upgrade profitieren würden, dann sollten Sie die Schätzungen für einen oder mehrere dieser Geschichten erhöhen, und das Upgrade als technische Aufgabe, die Geschichte hinzufügen.

Ist es, weil der Hersteller der Datenbank ist eine alte Version von Unterstützung abzuschneiden? In diesem Fall könnten Sie das Upgrade wie die Geschichte haben; so etwas wie: „Als der Abteilungsleiter, möchte ich sicher sein, dass wir die Unterstützung für die gesamte Software, so dass die Kontinuität des Unternehmens nicht gefährdet ist, wenn etwas schief geht“. dass drängt es auch, wenn. Im Allgemeinen ist diese Art der Vernunft ist nicht wirklich Teil eines Projektes, es sei denn, das Projekt so los ist seit langem der System-Software-Unterstützung geht aus.

Ist es für die Leistung? Dann sollte die Geschichte über einige Aspekte der Leistung der Anwendung sein, die verbessert werden muss, um Mehrwert zu liefern. So etwas wie: „Als CSR muß ich die Lage sein, Kundeninformationen in einer angemessenen Zeit zu holen, so dass die Kunden am Telefon mit unserem Service zufrieden sind“. Dann wird das Upgrade wird eine Aufgabe im Rahmen dieser Geschichte.

Ist es für einige völlig technischen Grund? Wenn Sie nicht identifizieren können, wie das Upgrade Geschäftswert liefern wird, warum dann würden Sie es tun? Warum wählt der Product Owner es für einen Sprint?

Es ist einfach „um die Datenbank-Upgrade“ oder vielleicht „Wenn die neue Version installiert ist, muss es eine Möglichkeit geben, die vorhandene Datenbank zu migrieren“. Wenn Sie bereits weitere Details zu diesem Schritt wissen, sind sie dann. Aber die Geschichte besteht meist um sicherzustellen, dass etwas nicht vergessen wird; es ist nicht detailliert sein.

Wenn Sie später diese Geschichte zu implementieren, können Sie es Fleisch aus (die Tabellen, brauchen wir eine oder mehr Sicherungen gibt es eine Fallback-Szenario, etc).

OTOH, wenn das Projekt komplexer ist, kann dies ein „Tag“ werden, wie ein Post-it feststellen, welche zu vielen Geschichten angebracht werden muß. Das heißt, Sie dies als eine „sub Geschichte“ enthalten muss alle Geschichten, die die Datenbank ändern. Wie Sie sehen können, ist diese „Projekt-Spanning Geschichten“ sind ein bisschen schwer mit agilen Methoden zu verfolgen.

Infrastruktur Geschichten müssen nicht die vorgeschriebene Geschichte Vorlage folgen. Nur aufschreiben, was getan werden muss, und schätzt dementsprechend

Wie wäre:

Als Anwendungsunterstützung Person ich auf die neueste Version von Datenbank sein wollen , weil es zuverlässiger / sicherer / was auch immer .

Sie könnten sogar Phrase Refactoring wie folgen aus:

Als Anwendungsentwickler Ich möchte, dass alle Datenklassen in einem Modul , so dass ich neue Felder sehr schnell auf die App hinzufügen .

1. Wer profitiert
2. Was Sie tun möchten,
3. Was ist der Nutzen

Im Idealfall möchten Sie nicht alle Geschichten 1 Entwickler haben, aber ein paar sinnvoll (Axt schärfen statt Bäume abzuholzen und das alles).

Answer 3

Answer 4

Answer 5

Aktualisieren der Datenbank eine der bei der Umsetzung eine andere Geschichte beteiligt Aufgaben sein, die direkten Wert für den Benutzer bringt, zum Beispiel ich als Benutzer einen neuen foo zu meiner Bar hinzufügen .

Wenn das Hinzufügen einer foo a bar erfordert eine Datenbank hinter den Kulissen aktualisieren, dann würden Sie diese Arbeit gehören in diese User Story zu implementieren.

Benutzer Geschichten formuliert werden auf diese Weise sicherzustellen, dass jede Arbeit direkt den Endverbraucher in irgendeiner Weise zugute kommt.

Answer 6

Dies wird in den Vordergrund, warum sind User Storys so groß.

Welchen Nutzen der Aktualisierung der Datenbank für den Endbenutzer geben? Keiner? Dann verbringen Sie nicht über die Zeit und Geld, um es zu tun. Verbringen Sie die Zeit und Geld bieten etwas, das den Wert Ihrer Endbenutzer geben wird.

Ist dies der Fall? Dann denken Sie über es andersrum. Vielleicht können Sie nur eine neue Funktion implementieren, wenn Sie die Version x Ihrer Datenbank-Software? In der Abhängigkeit der Geschichte, könnten Sie dieses Datenbank-Upgrade erwähnen erforderlich, um diese Funktion zu liefern.

tl; dr Sie nicht nur im Interesse der es aktualisieren. Stellen Sie sicher, Upgrade fügt greifbaren Mehrwert für Ihre Kunden.

Im Allgemeinen technische Aufgaben in der PB sind verpönt, weil sie sehr selten direkt liefert Mehrwert für die Kunden. Deshalb User Stories sind beliebt, weil sie Sie zwingen, um den Geschäftswert der Geschichte zu denken, und haben sie geliefert hat wird.

Also, warum aktualisieren Sie die Datenbank? Können Sie Geschäftswert in der Aktualisierung es, und warum sollte der Product Owner stimmen Sie lassen die Datenbank aktualisieren, anstatt den Bau neuer Funktionen identifizieren?

Ist es wegen einer neuen Funktion, die es ermöglichen wird, oder macht es einfacher, etwas in Ihrer Anwendung zu tun? In diesem Fall soll, dass etwas das PB-Element sein, und das Datenbank-Upgrade sollte eine Aufgabe innerhalb dieser Geschichte sein. Wenn Sie bereits Geschichten auf der PB haben, die von dem Upgrade profitieren würden, dann sollten Sie die Schätzungen für einen oder mehrere dieser Geschichten erhöhen, und das Upgrade als technische Aufgabe, die Geschichte hinzufügen.

Ist es, weil der Hersteller der Datenbank ist eine alte Version von Unterstützung abzuschneiden? In diesem Fall könnten Sie das Upgrade wie die Geschichte haben; so etwas wie: „Als der Abteilungsleiter, möchte ich sicher sein, dass wir die Unterstützung für die gesamte Software, so dass die Kontinuität des Unternehmens nicht gefährdet ist, wenn etwas schief geht“. dass drängt es auch, wenn. Im Allgemeinen ist diese Art der Vernunft ist nicht wirklich Teil eines Projektes, es sei denn, das Projekt so los ist seit langem der System-Software-Unterstützung geht aus.

Ist es für die Leistung? Dann sollte die Geschichte über einige Aspekte der Leistung der Anwendung sein, die verbessert werden muss, um Mehrwert zu liefern. So etwas wie: „Als CSR muß ich die Lage sein, Kundeninformationen in einer angemessenen Zeit zu holen, so dass die Kunden am Telefon mit unserem Service zufrieden sind“. Dann wird das Upgrade wird eine Aufgabe im Rahmen dieser Geschichte.

Ist es für einige völlig technischen Grund? Wenn Sie nicht identifizieren können, wie das Upgrade Geschäftswert liefern wird, warum dann würden Sie es tun? Warum wählt der Product Owner es für einen Sprint?

Es ist einfach „um die Datenbank-Upgrade“ oder vielleicht „Wenn die neue Version installiert ist, muss es eine Möglichkeit geben, die vorhandene Datenbank zu migrieren“. Wenn Sie bereits weitere Details zu diesem Schritt wissen, sind sie dann. Aber die Geschichte besteht meist um sicherzustellen, dass etwas nicht vergessen wird; es ist nicht detailliert sein.

Wenn Sie später diese Geschichte zu implementieren, können Sie es Fleisch aus (die Tabellen, brauchen wir eine oder mehr Sicherungen gibt es eine Fallback-Szenario, etc).

OTOH, wenn das Projekt komplexer ist, kann dies ein „Tag“ werden, wie ein Post-it feststellen, welche zu vielen Geschichten angebracht werden muß. Das heißt, Sie dies als eine „sub Geschichte“ enthalten muss alle Geschichten, die die Datenbank ändern. Wie Sie sehen können, ist diese „Projekt-Spanning Geschichten“ sind ein bisschen schwer mit agilen Methoden zu verfolgen.

Infrastruktur Geschichten müssen nicht die vorgeschriebene Geschichte Vorlage folgen. Nur aufschreiben, was getan werden muss, und schätzt dementsprechend

Wie wäre:

Als Anwendungsunterstützung Person ich auf die neueste Version von Datenbank sein wollen , weil es zuverlässiger / sicherer / was auch immer .

Sie könnten sogar Phrase Refactoring wie folgen aus:

Als Anwendungsentwickler Ich möchte, dass alle Datenklassen in einem Modul , so dass ich neue Felder sehr schnell auf die App hinzufügen .

1. Wer profitiert
2. Was Sie tun möchten,
3. Was ist der Nutzen

Im Idealfall möchten Sie nicht alle Geschichten 1 Entwickler haben, aber ein paar sinnvoll (Axt schärfen statt Bäume abzuholzen und das alles).

Answer 7

Dies wird in den Vordergrund, warum sind User Storys so groß.

Welchen Nutzen der Aktualisierung der Datenbank für den Endbenutzer geben? Keiner? Dann verbringen Sie nicht über die Zeit und Geld, um es zu tun. Verbringen Sie die Zeit und Geld bieten etwas, das den Wert Ihrer Endbenutzer geben wird.

Ist dies der Fall? Dann denken Sie über es andersrum. Vielleicht können Sie nur eine neue Funktion implementieren, wenn Sie die Version x Ihrer Datenbank-Software? In der Abhängigkeit der Geschichte, könnten Sie dieses Datenbank-Upgrade erwähnen erforderlich, um diese Funktion zu liefern.

tl; dr Sie nicht nur im Interesse der es aktualisieren. Stellen Sie sicher, Upgrade fügt greifbaren Mehrwert für Ihre Kunden.

Answer 8

Im Allgemeinen technische Aufgaben in der PB sind verpönt, weil sie sehr selten direkt liefert Mehrwert für die Kunden. Deshalb User Stories sind beliebt, weil sie Sie zwingen, um den Geschäftswert der Geschichte zu denken, und haben sie geliefert hat wird.

Also, warum aktualisieren Sie die Datenbank? Können Sie Geschäftswert in der Aktualisierung es, und warum sollte der Product Owner stimmen Sie lassen die Datenbank aktualisieren, anstatt den Bau neuer Funktionen identifizieren?

Ist es wegen einer neuen Funktion, die es ermöglichen wird, oder macht es einfacher, etwas in Ihrer Anwendung zu tun? In diesem Fall soll, dass etwas das PB-Element sein, und das Datenbank-Upgrade sollte eine Aufgabe innerhalb dieser Geschichte sein. Wenn Sie bereits Geschichten auf der PB haben, die von dem Upgrade profitieren würden, dann sollten Sie die Schätzungen für einen oder mehrere dieser Geschichten erhöhen, und das Upgrade als technische Aufgabe, die Geschichte hinzufügen.

Ist es, weil der Hersteller der Datenbank ist eine alte Version von Unterstützung abzuschneiden? In diesem Fall könnten Sie das Upgrade wie die Geschichte haben; so etwas wie: „Als der Abteilungsleiter, möchte ich sicher sein, dass wir die Unterstützung für die gesamte Software, so dass die Kontinuität des Unternehmens nicht gefährdet ist, wenn etwas schief geht“. dass drängt es auch, wenn. Im Allgemeinen ist diese Art der Vernunft ist nicht wirklich Teil eines Projektes, es sei denn, das Projekt so los ist seit langem der System-Software-Unterstützung geht aus.

Ist es für die Leistung? Dann sollte die Geschichte über einige Aspekte der Leistung der Anwendung sein, die verbessert werden muss, um Mehrwert zu liefern. So etwas wie: „Als CSR muß ich die Lage sein, Kundeninformationen in einer angemessenen Zeit zu holen, so dass die Kunden am Telefon mit unserem Service zufrieden sind“. Dann wird das Upgrade wird eine Aufgabe im Rahmen dieser Geschichte.

Ist es für einige völlig technischen Grund? Wenn Sie nicht identifizieren können, wie das Upgrade Geschäftswert liefern wird, warum dann würden Sie es tun? Warum wählt der Product Owner es für einen Sprint?

Answer 9

Es ist einfach „um die Datenbank-Upgrade“ oder vielleicht „Wenn die neue Version installiert ist, muss es eine Möglichkeit geben, die vorhandene Datenbank zu migrieren“. Wenn Sie bereits weitere Details zu diesem Schritt wissen, sind sie dann. Aber die Geschichte besteht meist um sicherzustellen, dass etwas nicht vergessen wird; es ist nicht detailliert sein.

Wenn Sie später diese Geschichte zu implementieren, können Sie es Fleisch aus (die Tabellen, brauchen wir eine oder mehr Sicherungen gibt es eine Fallback-Szenario, etc).

OTOH, wenn das Projekt komplexer ist, kann dies ein „Tag“ werden, wie ein Post-it feststellen, welche zu vielen Geschichten angebracht werden muß. Das heißt, Sie dies als eine „sub Geschichte“ enthalten muss alle Geschichten, die die Datenbank ändern. Wie Sie sehen können, ist diese „Projekt-Spanning Geschichten“ sind ein bisschen schwer mit agilen Methoden zu verfolgen.

Answer 10

Infrastruktur Geschichten müssen nicht die vorgeschriebene Geschichte Vorlage folgen. Nur aufschreiben, was getan werden muss, und schätzt dementsprechend

Answer 11

Wie wäre:

Als Anwendungsunterstützung Person ich auf die neueste Version von Datenbank sein wollen , weil es zuverlässiger / sicherer / was auch immer .

Sie könnten sogar Phrase Refactoring wie folgen aus:

Als Anwendungsentwickler Ich möchte, dass alle Datenklassen in einem Modul , so dass ich neue Felder sehr schnell auf die App hinzufügen .

1. Wer profitiert
2. Was Sie tun möchten,
3. Was ist der Nutzen

Im Idealfall möchten Sie nicht alle Geschichten 1 Entwickler haben, aber ein paar sinnvoll (Axt schärfen statt Bäume abzuholzen und das alles).

Answer 12

Answer 13