schätzung

Einblicke in die Anwendung einer MonteCarlo-Simulation zur Projektprognose, eine Methode, die Variabilität und Unsicherheit meistert. Show Notes:

Jenny und David sprechen über die Quelle der Jugend. Außerdem darüber, warum diese in Form von Filtern und Social Media generell nicht die geilste Eigenschaft ist. Zuletzt war Jenny noch ihr Auto waschen, wobei sie genug Testosteron für den Rest der Zeit erblickt hat. Music by beatlach - http://bit.ly/MMH-Beatz

In dieser Folge haben wir Adrian Salamon von tarent solutions zu Gast. Adrian ist Scrum Master und stellt uns das von ihm mit seinem Team entwickelte Vorgehen des sogenannten "Feature Breakdown" vor. Ihr wollt gegenüber euren Stakeholdern aussagefähig sein, wann ein Feature kommt? Ihr wollt alles splitten? Zugleich wollt ihr nicht in irrsinnig langen Refinement Sessions sitzen? Dann hört euch diesen spannenden Erfahrungsbericht des Teams von tarent solutions an. Ausgangslage: Der Product Owner (vom Auftraggeber) und das externe Team waren mit ihrem Refinement Prozess nicht sonderlich zufrieden. Die User Stories waren schlecht geschnitten und hin und wieder fehlte auch mal eine Story, um den vollen Nutzerwert liefern zu können. Die Refinement Meetings waren tendenziell zu lang und zu detailliert. Zugleich baten die Stakeholder schon oft sehr früh um zumindest grobe Schätzungen (Zeit/Geld) für einzelne Features. Keiner war so richtig zufrieden mit der Situation. Dies war der Startpunkt einer Lernreise mit verschiedenen Experimenten, über die Adrian im Gespräch ausführlich berichtet und seine Learnings teilt. Dabei ist das Team an Behavioral Driven Development, Three-Amigos-Meetings und mehrstufigen QA-Checks vorbeigekommen. Aber immer blieb eine Unzufriedenheit: entweder mit der Geschwindigkeit der Meetings und/oder mit der Qualität und Sinnhaftigkeit der User Stories. Nach einigen Iterationen fand Adrian zusammen mit seinen Teammitgliedern von tarent sowie den Stakeholdern auf Kundenseite ein Vorgehen ("Feature Breakdown"), welches allen Beteiligten sehr hilft, (zu) große Features in effektiver Weise runter zu brechen. Dabei wird durch Adrian als Scrum Master auf ein sehr striktes Timeboxing geachtet, was zu großer Effizienz führt. Das vorgestellte Verfahren wird in dem international verteilten Team von tarent natürlich komplett remote durchgeführt. Adrian Salamon hat das ganze Vorgehen auch in einem Blogpost seiner Firma ausführlich beschrieben: https://www.tarent.de/blog/improving-the-flow Im Kontext dieser Folge könnten auf diese Episoden für euch relevant sein: - Hilfe, mein Backlog ist explodiert - Mein Freund der Scrum Master Wenn ihr direkten Kontakt zu Adrian aufnehmen möchtet, um weitere Fragen zu stellen, erreicht ihr ihn z.B. per Mail: a.salamon@tarent.de Wenn euch die Folge gefällt, freuen wir uns über eine positive Bewertung in eurer Podcast App oder als Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Instagram oder Twitter.

Meine Erfahrung ist, dass viele Softwareentwickler nicht gerne ihre Arbeit schätzen. Schätzen ist jedoch wichtig für das Projektmanagement, um die Planung und dem Kunden ein Angebot zu machen. Die Schätzung ist die Ausgangslage für die Sprint-Planung. Und die früheste Fertigstellung spielt eine entscheidende Rolle für den Kunden oder Fachbereich. In dieser Folge schauen wir uns die häufigsten Fehler rund um Schätzen an.