Die 3 größten User-Story-Mythen

Erstellt am 27 Februar 2019
von Schreibe einen Kommentar
User Story Mythen

In meiner Arbeit mit agilen Teams und als Trainer höre ich immer wieder Aussagen über User Stories, die von der ursprünglichen Intention abweichen und in der Praxis Probleme verursachen. Zeit, mit ein paar der häufigsten Mythen aufzuräumen.

Mythos #1: In Scrum wird eine Anforderung als User-Story dokumentiert.

Das kann man so machen, muss man aber nicht. Der Scrum Guide lässt völlig offen, wie Backlog Items zu dokumentieren sind. Ich persönlich mag User Stories, weil sie die Perspektive vom System auf den Nutzer verschieben. Aber vorgeschrieben ist das nicht.

Mythos #2: Wenn man User-Stories schreibt, dann muss man ein bestimmtes Template benutzen.

Wahrscheinlich denken Sie an: Als <Nutzer> möchte ich <Funktion> damit <Erfülltes Bedürfnis>.
Das Konzept der User Story hatte ursprünglich nichts mit diesem Template zu tun. Mike Cohn hat das Template dann später populär gemacht. Es ist genauso möglich, User Stories informell zu dokumentieren und auf das Template zu verzichten.

Mythos #3: User Stories werden mit Story Points geschätzt.

Als Scrum Master habe ich Teams beobachtet, die sich mit Diskussionen um Story Points, Schätzungen und Velocity verrückt gemacht haben.

Es gibt eine einfache Alternative. Das Team vereinbart kleine Stories. So 1-2 Umsetzungstage für das Team. Dann zählt es nach dem Sprint die Stories, die es fertiggestellt hat. Schon hat man die Velocity.


Sie sehen: Der Umgang mit User Stories ist in der Praxis gar nicht so schwierig. Wie setzen Sie User Stories in der Praxis ein? Ich freue mich über einen Kommentar!


Veranstaltungstipp

Die perfekte Gelegenheit zum weiteren Aufräumen der Mythen finden Sie in knapp zwei Wochen auf der REConf 2019 vom 11.-15. März in München.




Mit Speed ins Requirements Engineering einsteigen

Erstellt am 23 Januar 2019
von Schreibe einen Kommentar

Sie wollen fundiert, gleichzeitig tief ins Requirements Engineering einsteigen? Und das in kürzester Zeit? Oder einer Ihrer Kollegen? Dann gibt es dazu die ideale Gelegenheit auf der REConf in München: Starten Sie mit meinem neugestalteten RE-Einsteiger-WorkshopAnforderungen sind Kommunikation – RE Basics“ am 11.3.2019 nachmittags. Danach bieten sich Ihnen noch zwei weitere Tage, um hochkarätige Keynotes und Vorträge zu verschiedensten Themen des RE anzuhören, sowie sich mit Kollegen und Experten auszutauschen und zu vergnügen.

Anforderungen sind Kommunikation – RE Basics

Anforderungen sind Kommunikation

New Work und agiles Arbeiten

Erstellt am 25 Oktober 2018
von Schreibe einen Kommentar

Innovative Personal Management-Ansätze wie flexible Arbeitszeiten und Ortsunabhängigkeit verändern derzeit die Arbeitswelt vieler Arbeitnehmer. Welche Vorteile ergeben sich daraus?

 
New Work und agiles Arbeiten sind Begriffe, die ich in letzter Zeit häufiger höre. Das hat zugegebenermaßen auch damit zu tun, dass ich vor Kurzem bei HOOD Group im Marketing angefangen habe, aber nicht nur. Innovative Management-Ansätze wie flexible Arbeitszeiten und Ortsunabhängigkeit verändern derzeit auch die Arbeitswelt vieler meiner Freunde. Lasst uns doch einfach mal schauen, welche Vorteile sich daraus ergeben.

Wie detailliert muss ich spezifizieren?

Erstellt am 27 September 2018
von Schreibe einen Kommentar

Dieser Frage widme ich mich heute, eine der oft gestellten Fragen in unseren Kursen.

Stakeholder-Analyse in Entwicklungsprojekten

Erstellt am 22 Mai 2018
von Schreibe einen Kommentar

Die Stakeholder-Analyse bezeichnet die Identifikation der Projektteilnehmer, weiterer Personen und Institutionen, die ein Interesse an einem Entwicklungsgegenstand haben. Durch genaueres Untersuchen der Einstellung und Beziehung der Stakeholder zum Entwicklungsgegenstand bekommen die Projektverantwortlichen ein besseres Verständnis für die Erfolgsfaktoren des Entwicklungsgegenstandes.

Anforderungen strukturieren – 4. Das Informationsmodell

Erstellt am 25 April 2018
von Schreibe einen Kommentar
This entry is part 4 of 4 in the series Anforderungen strukturieren

Heute der 4. Teil der Serie „Anforderungen strukturieren“ mit der Frage: „Wie gestaltet man eine Struktur mit mehreren Anforderungsdokumenten, Spezifikationen und anderen Anforderungsartefakten?“. Im sogenannten Anforderungs-Informationsmodell  wird definiert, welche 

Jung bleiben mit RE

Erstellt am 2 August 2016
von Schreibe einen Kommentar

Wir alle werden älter, sowohl körperlich wie auch geistig. Dagegen lässt sich leider langfristig nicht viel ändern. Medizinisch bewiesen sind gewisse gesundheitliche „Best Practices“ zur Anwendung in unseren privaten Lebensprojekten. Ausreichend Schlaf, Sport, gesunde Ernährung und wenig Stress können den Alterungsprozess bekannterweise verlangsamen.

Ziele und Nutzen des systematischen Umgangs mit Anforderungen

Erstellt am 19 Juli 2016
von Schreibe einen Kommentar

Ziele von Anforderungen und Requirements EngineeringKürzlich wurde ich wieder gefragt, wie sich der Aufwand von Requirements Engineering rechtfertigen lässt. Immer noch beobachte ich, dass die Tätigkeit des „systematischen Umgangs mit Anforderungen“, dies ist eine moderne Übersetzung des englischen Begriffs „Requirements Engineering and Management“, zu wenig Akzeptanz innerhalb der Unternehmen findet. Es werden verschiedenste Gegenargumente vorgetragen: Für das Projektmanagement ist es viel zu teuer, für die Entwickler und Fachabteilungen ist es „unmotivierter Mehraufwand“ oder „Overhead für Dokumentation“, für manche agile Teams ist es „alter Hut“ und für erfahrene, gewachsene Fachabteilungen ist es „nicht notwendig, das haben wir schon immer so, ohne Anforderungen, gemacht“.

Gewiss, der systematische Umgang mit Anforderungen kostet Zeit und Geld, und der Aufwand muss adäquat an die Struktur und die Gegebenheiten der Organisation, des zu entwickelnden Produktes oder Dienstleistung angepasst werden.

Lücken und Brücken im Requirements Engineering – GAPS and BRIDGES

Erstellt am 10 März 2015
von Schreibe einen Kommentar

Schon wieder Probleme mit den Zulieferern oder dem Lastenheft? Die Qualität des Produkts stimmt nicht? Die Entwicklung braucht zu lange? Die Produktpalette wird immer komplexer? Wir führen ja Requirements Engineering ein, aber …? Wo sollte ich ansetzen, wo ist speziell bei uns die Lücke im Entwicklungsprozess?

Mülltrennung in der Softwareentwicklung

Erstellt am 6 März 2013
von Schreibe einen Kommentar

Wussten Sie, dass es jetzt auch den „grünen Punkt“ in der Softwareentwicklung gibt? Ja, das Trennen nach recycelbaren Entwicklungsergebnissen macht Sinn. Andere wiederum müssen „entsorgt“ werden – die meisten Halden werden in unserer Industrie als Archive bezeichnet. Wenn Sie erfahren wollen, wie Sie die richtige Mülltrennung hinbekommen können, lesen Sie weiter …