Zeitschätzungen und Epics als Releases

Investoren benötigen für bestimmte Meilensteine ​​Datumsangaben für hochrangige Schätzungen.

Das ist nicht wirklich im Sinne von Scrum... mehr Wasserfall. Dennoch ist es nicht so, dass Sie einfach sagen können: „Entschuldigung, Investoren, keine erste Schätzung für Sie ermittelte Geschwindigkeit (die Sie wahrscheinlich nicht haben, wenn Sie gerade erst mit Scrum anfangen), berechnen Sie die Zeit, die für die Erledigung aller Arbeiten benötigt wird.Wenn möglich, lassen Sie Ihre Investoren verstehen, dass dies nur eine erste, grobe Schätzung ist, und er wird angepasst, sobald weitere Informationen verfügbar sind. Geben Sie nach Möglichkeit auch einen Wertebereich an .

Mir wurde gesagt, dass wir EPICS idealerweise NICHT verwenden sollten, um eine Veröffentlichung darzustellen.

Im Scrum Guide steht nichts über Epics oder deren Fehlen, also tun Sie einfach das, was für Ihr Team am sinnvollsten ist. Lassen Sie sich oder Ihr Team nicht von einem Tool oder einer Konvention einschränken.

Schließlich erhielt ich widersprüchliche Meinungen darüber, ob operative Aspekte der Produktentwicklung in TFS aufgenommen werden sollten oder nicht.

Wenn CodeGnome mir verzeiht, dass ich sein Gesetz gestohlen habe...

"Keine unsichtbare Arbeit, niemals!" — Transparenzgesetz von CodeGnome

Sie sollten diese Entwickleraufgaben im Auge behalten. Allerdings sollten Sie nach Möglichkeit zwischen diesen Entwickleraufgaben und normalen, geschäftsbezogenen Stories unterscheiden. Denn schließlich sollten Leute außerhalb des Entwicklungsteams zwar das Scrum Board sehen können, sich aber nicht um diese Aufgaben kümmern.

• Investoren benötigen für bestimmte Meilensteine ​​hochrangige Datenschätzungen. Wann sollten wir zum Beispiel damit rechnen, dass ein MVP (Minimum Viable Product) fertig ist.

Es ist vielleicht noch zu früh zu sagen ... sind Sie der Scrum Master ? Das ist wirklich eine Frage für die PO. Aber am Ende des Tages, bis Sie einige Sprints auf dem Buckel haben, können Sie keine realistischen Schätzungen abgeben. Sehen Sie sich den Twitter-Account von @WoodyZuill an, um Einzelheiten über die #NoEstimates-Bewegung zu erfahren.

• Idealerweise sollten wir EPICS verwenden, um eine Veröffentlichung darzustellen. Aber da ich in TFS keinen anderen praktikablen Weg sehe, dies zu erreichen, habe ich ein Epic namens „Minimum Viable Product“ erstellt und die gewünschten Funktionen dort hinzugefügt. Gedanken?

Eine Veröffentlichung kann viele Eics oder Teile vieler Epics enthalten ... Sie versuchen also, MVP mit kontinuierlicher Bereitstellung in Einklang zu bringen. Die bessere Option für Ihre Investoren wäre ... wie erhöhen wir das, was wir haben, um etwas Wertvolleres zu sein? Und damit einen kürzeren Blick auf das Projekt werfen. Es ist ein Wasserfalldenken, um zu sagen, dass Sie in 6 Monaten mit Ihrem MVP live sein werden. Es ist eine agile Sichtweise zu sagen, dass Ihr Produkt in 6 Monaten ein besseres Produkt mit (hoffentlich) vielen kleineren Funktionserweiterungen sein wird.

• Schließlich erhielt ich widersprüchliche Meinungen darüber, ob operative Aspekte der Produktentwicklung in TFS aufgenommen werden sollten oder nicht. Dinge wie „Framework entscheiden“, „Entwicklungsumgebung einrichten“ usw. Ein Scrum Master sagt mir, dass wir dies NICHT tun sollten, weil SCRUM nur die zu liefernden Produkte auflisten sollte, während der andere mir sagte, dass dies offensichtlich sei Dinge sollten vorhanden sein, da wir sie in der Produktentwicklung berücksichtigen müssen.

Da diese nicht zum Leben erweckt werden, ist das Nein die richtige Antwort. Es gibt einen Hinweis in einigen der Aufgabennamen, z. B. "Diskutieren" & "Evaluieren".

Ich mag die Antwort von @sarov und wollte nur etwas TFS-bezogenes Bump in Bezug auf das Scrum-Bump hinzufügen, vielleicht mit einem kleinen zusätzlichen Scrum-Bump.

Investoren benötigen für bestimmte Meilensteine ​​Datumsangaben für hochrangige Schätzungen. Wann sollten wir zum Beispiel damit rechnen, dass ein MVP (Minimum Viable Product) fertig ist. Allerdings können nur Aufgaben in Stunden gemessen werden. Wie kann ich den Investoren in diesem Fall einen guten Satz vorgeschlagener Meilensteindaten zur Verfügung stellen?

(Scrum-Theorie) Dies ist etwas, das vollständig in den Zuständigkeitsbereich des Product Owners fällt und nicht in TFS gehört. TFS ist eher ein Aufwands-Tracking-System als ein Zeit-Tracking-System.

(Scrum-Praxis) Wenn Sie in Scrum planen, ist es eine gute Praxis, Ihr Entwicklungsteam jedes Ihrer Backlog-Elemente in relativen Größen basierend auf numerischen Punkten schätzen zu lassen. Während Ihr Entwicklungsteam diese Punkte verwenden kann, um zu entscheiden, wie viel Arbeit für den nächsten Sprint prognostiziert werden soll, kann Ihr Product Owner sie verwenden, um mehrere Sprints zu prognostizieren und wann einige seiner Meilensteine ​​​​erreicht werden könnten.

(tfs/vsts) Ich würde versuchen, Ihren Product Owner darin zu schulen, wie man den Wert überwacht. Es gibt gute Schulungen sowohl von Scrum.org als auch von der Scrum Alliance. Wenn Sie VSTS (Cloud TFS) verwenden, erhalten Sie die Erweiterung „Delivery Plan“ ( https://marketplace.visualstudio.com/items?itemName=ms.vss-plans ), mit der Sie einfach und visuell zukünftige Sprints planen können. aber es geht immer noch nicht um Stunden.

(Scrum-Theorie) Wenn jemand Ihren Investoren Garantien gibt, dann respektieren Sie sie letztendlich nicht. Es ist grundsätzlich unmöglich, im Voraus zu bestimmen, wie lange die Lieferung eines Rückstandsartikels dauert und wann er verfügbar sein wird. Stellen Sie sicher, dass Sie sich auf Prognosen konzentrieren, nicht auf Schätzungen.

Mir wurde gesagt, dass wir EPICS idealerweise NICHT verwenden sollten, um eine Veröffentlichung darzustellen. Aber da ich in TFS keinen anderen praktikablen Weg sehe, dies zu erreichen, habe ich ein Epic namens „Minimum Viable Product“ erstellt und die gewünschten Funktionen dort hinzugefügt. Gedanken?

(Scrum-Theorie) Der Scrum-Leitfaden spricht nicht über Epics oder Features, weil sie alle nur Backlog-Elemente sind ...

(Scrum-Praxis) Es gibt viele Möglichkeiten, Ihre Arbeit zu organisieren, und es liegt an Ihnen, wie. Eine gängige Praxis ist jedoch, dass Epics, Features und Backlog-Elemente alle dasselbe darstellen, nur mit unterschiedlichem Grad an Granularität. Da sie sich alle im Ausführungsablauf befinden, müssen sie alle den Wert darstellen, der dem Kunden geliefert wird.

(tfs/vsts) Hier gibt es keine festen Regeln, TFS verfügt jedoch über eine sofort einsatzbereite Methode zur Verwaltung zeitbasierter Vorhersagen. Sie haben bereits Sprints im Bereichspfad und da er hierarchisch ist, können Sie viele Ebenen hinzufügen. Eine gängige Methode ist:

\Release 1\
\Release 1\Sprint 1
\Release 1\Sprint 2
\Release 1\Sprint 3
\Release 1\Sprint 4 
\Release 2\
\Release 2\Sprint 5
\Release 2\Sprint 6
\Release 2\Sprint 7

Da Sie „Teams“ auf bestimmte Pfade verweisen können, können Sie ein zusätzliches Team erstellen und es auf Releases verweisen, wodurch Ihr Product Owner eine hochrangige Planungsfunktion erhält. Ich habe einen ziemlich detaillierten Beitrag zur Konfiguration erstellt: https://nkdagility.com/creating-nested-teams-visual-studio-alm/

Schließlich erhielt ich widersprüchliche Meinungen darüber, ob operative Aspekte der Produktentwicklung in TFS aufgenommen werden sollten oder nicht. Dinge wie „Framework entscheiden“, „Entwicklungsumgebung einrichten“ usw. Ein Scrum Master sagt mir, dass wir dies NICHT tun sollten, weil Scrum nur die zu liefernden Produkte auflisten sollte, während der andere mir sagte, dass es offensichtlich sei, dass diese Dinge sollten vorhanden sein, da wir sie in der Produktentwicklung berücksichtigen müssen.

(Scrum-Theorie) Ihr Product Owner ist für das Product Backlog, seinen Inhalt und das Verständnis aller dafür verantwortlich. In Anbetracht dessen kann es je nach Team, Produkt oder Unternehmen sinnvoll sein, diese Elemente im Backlog zu haben, oder auch nicht.

(Scrum-Praxis) Viele Scrum-Teams werden klar gekennzeichnete „Architektur“- oder „Infrastruktur“-Elemente in das Product Backlog aufnehmen, um sicherzustellen, dass Dinge nicht vergessen werden. [diese Praxis kommt von SAFe]

(tfs/vsts) Ab TFS 2015 gibt es ein zusätzliches Feld für jedes Ausführungsarbeitselement (Epic, Feature und Backlog Item), das eine Dropdown-Liste mit den Werten „Business“ und „Architectural“ ist.

(Scrum-Praxis) Eine widersprüchliche gute Praxis besteht darin, niemals etwas in das Product Backlog aufzunehmen, das Ihre Stakeholder nicht verstehen würden.

(Warnung) Was auch immer Sie wählen, stellen Sie sicher, dass Sie technische Schulden transparent darstellen können.