Scrum User Group Hamburg

Scrum User Group Hamburg

Gruppe zum Austausch über Scrum und Agilität. Wir treffen uns alle zwei Monate zu sog. Scrumtischen

Andreas Wienes Andreas Wienes Moderator

Wie suchst du nach Jobs?

Bitte unterstütze mich durch eine 30 sekündige und anonyme Umfrage zum Thema "Wie suchst du nach Jobs?" Vielen Dank!

Ihr könnt diesen Link natürlich auch gerne teilen.
:)

https://docs.google.com/forms/d/1U6C0Zi1tK4tVw18_Z1XiE-6BIK4muttgQ35PhNpx90g/viewform?usp=send_form

Meinert Schwartau Meinert Schwartau

Releaseplan

Hallo,

wie erstellt ihr für ein großes Projekt, dass über mehrere Monate geht, einen Release Plan nach jedem Sprint?

Angenommen die Userstories die wahrscheinlich in den nächsten zwei/drei Sprints (Dauer je zwei Wochen) genommen werden sind schon relativ fein definiert, so dass ihr sie gut einschätzen könnten. Die Themengebiete die später kommen sind zwar grob bekannt, hier lohnt es sich aber nicht sie schon so fein zu definieren, da die Erfahrung gezeigt hat, dass diese dann noch mal komplett umgeschrieben werden würden.

Statt 
"Als Kunde möchte im Schritt 1 des Bestellvorganges eine abweichende Lieferadresse aus meinem Adressbuch auswählen können"
"Als Kunde möchte im Schritt 1 des Bestellvorganges meine Rechnungsadresse ändern können"
"Als Kunde möchte ich dass meine Adresse mittels Webservice XYZ auf Plausibilität geprüft wird" usw.

Hat man also nur eine sehr grobe Story (Epic) mit sehr hohen Story Points:
"Also Kunde möchte ich während des Bestellvorganges eine Liefer- und Rechnungsadresse auswählen können"

Wenn ihr nun also nach jeden Review eine grobe Perspektive abgeben wollt, wann ihr denn mit allen Stories aus dem aktuellen Backlog LIVE gehen könntet, wie macht ihr das?

Mike Cohn schreibt in seinem Buch, dass man seine schlechteste und beste Velocity aus seinen vergangenen Sprints ableiten und daraus dann bestimmen soll wo man rauskommt. 

Also: 
Schlechteste Velocity: 20 SP
Beste Velocity: 30 SP
Noch offene Storypoints im Backlog: 200 SP
Sprintlänge 2 Wochen
Mit der schlechtesten Velocity von 20 SP pro Sprint bräuchte man hierfür 200 / 20 = 10 Sprints 
Mit der besten Velocity von 30 SP bräuchte man 200 / 30 = 7 Sprints

Ich tue mich nun aber schwer damit zu sagen, dass wir aus aktueller Sicht in 7 - 10 Sprints fertig werden. Der Grund hierfür ist, dass es viele kleine Stories gibt die relativ gut zu überblicken und wahrscheinlich auch gut geschätzt sind. Bei denen könnte ich relativ gut sagen wann wir die denn ungefähr fertig haben werden wenn wir nur sie bearbeiten würden. Die großen Stories aber, die später noch runtergebrochen werden müssen, haben eine sehr hohe Ungenauigkeit. Das bedeutet dann, dass sie vll. statt 20 SP eher 40 SP hätten sein müssen was in dem Beispiel oben eben mal eine Ungenauigkeit von einem Sprint ist. 

Die Frage ist also, wie erstellt ihr euren Releaseplan? Mike Cohn und Mitch Lacey haben beiden in ihren Büchern geschrieben, dass man die Unsicherheit bei den großen Epics in seinem Releasplan berücksichtigen soll. Nur leider haben sie nicht geschrieben wie - oder ich habe es überlesen.

Wenn ihr auch solche groben Stories habt, wie drückt ihr im Releaseplan eure Unsicherheit bei ihnen aus? Wie erstellt ihr euren Releaseplan?

Viele Grüße
Meinert Schwartau

1 more comment
Last comment:
Only visible to XING members.

Kalibrierte Story Points

This content will be displayed once you're logged in.
1 more comment
Last comment:
Only visible to XING members.

Ich glaube dass es ist möglich, Story Points aller Teams so zu kalibrieren, wenn aller Teams haben Gemeinsames Baseline, wie Mike Cohn erklärt:
http://www.mountaingoatsoftware.com/blog/establishing-a-common-baseline-for-story-points

Wir kalibrieren Story Points innerhalb ein Projekt, aber nicht hinüber Projekte.

Wir haben nicht Gemeinsames Baseline hinüber Projekte. Jede Projektteam hat sein besitzen Definition und Baseline. So wir in unseren Projektteams Story Points nicht kalibrieren.

Ich glaube aller Teams zu Story Points kalibrieren ist nicht wichtig.

Viele Grüße,
Antony

Only visible to XING members.

Die Frage nach der richtigen Software

Hallo zusammen,

der Weg von Kundenanforderungen über einen Systementwurf bis zu einer Story ist lang. Wenn ich nach SPICE arbeite, dann ist es unumgänglich diesen Weg tracebar zu halten. Es gibt diverse Tools, die diese Aufgabe übernehmen können: Wir verwenden z.B. eine Kombination aus Word, Excel, Enterprise Architect und Jira mit dem Greenhopper Plugin.

Nun stehen Tools wie Polarion oder in-Step zur Diskussion.

Hat schon jemand Erfahrungen mit Anforderungsmanagement und letztendlich SCRUM in diesem Umfeld gemacht? Ich würde mich freuen von Euren Erfahrungen zu hören.

Gruß
Björn

Stephan Eberle Stephan Eberle

Hallo Herr Keck,

ich habe einmal in einem größeren Scrum-Projekt mit Polarion (damals "Track & Wiki") gearbeitet und empfand das Arbeiten damit als sehr angenehm, da sich z.B. Änderungen an den Featurebeschreibungen sofort und einfach durchführen ließen und gleichzeitig eine Historie der Änderungen verfügbar ist.

Gut fand ich auch die Priorisierung der Issues mit Zahlenwertern und nicht mit "High/Low/...", was mehr Feinheit und Übersicht gibt.

Nichts ist IMHO schlimmer, als ein Wordfile-Chaos abseits des Work-Trackers zu verwenden. Damals fehlte mir lediglich das Taskboard (gibt es jetzt aber wohl auch alles als Plugin).

Ansonsten finde ich die Kombination aus Jira+Greenhopper+Confluence sehr angenehm.

Bei entsprechendem Budget würde ich mich selber aber wohl doch wieder für Polarion entscheiden.

Viele Grüße,
Stephan

PS: Ist natürlich nur meine subjektive Meinung.