14728 members | 2882 posts | Public Group

Scrum ist ein agiles Produktentwicklungsframework. Für Menschen die Scrum einsetzen dient die Gruppe dem Erfahrungsaustausch.

Tue, 7/6/2021 7:00 PM - 10:00 PM

Welche Unterstützung hilft dem Team gut durch die Forming, Storming und Norming Phase?... Read more

Tue, 7/6/2021 7:00 PM - 10:00 PM



Schaut euch das an. Beste Voraussetzungen für einen gelungenen Start in die agile Transformation!

Weltweit gibt es nur 22 zertifizierte Large-Scale Scrum (LeSS) Trainer! Super cool, wenn einer davon - der großartige Robert Briese - bei uns von seinen Erfahrungen bei der Durchführung eines Sprint Reviews mit mehreren verteilten Teams berichtet!

This post is only visible to logged-in members. Log in now
Meine Erfahrung zeigt, dass die Menge an Abhängigkeiten - Dependencies - durch einen geschickten Setup der Scrum Teams reduziert werden kann. Sichtwort: Feature Teams. Ganz wegbekommen, so denke ich, wird nicht funktionieren.
This post is only visible to logged-in members. Log in now

A Scrum team cannot deliver value without a good Product Owner. This is for me the most important role and it is not easy to keep an Agile balance between a long term business vision that could lead the team to success and the ability to adapt to change after receiving customer feedback. In this article, Zuzi Šochová shares a list of the most common mistakes made by Product Owners.

Your blog says that one of the mistakes Product Owners make is, that they are too focuse on estimates. I have a different opinion. For me, a good Scrum Team is a team that has usually roughly implemented the (Sprint) Plan at the end of the sprints. Approximately means, as a rule, 80% +. ADDED VALUE is generated through the implementation of issues (User Stories, etc.). If significantly less is implemented continuously than planned, neither the customer nor the Product Owner are satisfied. Planning is the matching of supply and demand. The matching of available capacities versus estimated efforts the implementation costs. If the effort for the implementation of the requirements is not AT LEAST ROUGHLY ESTIMATED, planning cannot work.
What the author of this article (Zuzana Šochová) wrote is that "In the Agile world, it’s not about delivering features. It’s about achieving certain business value. And those two have often only very little in common." And I agree with her that if at the end of the sprint you have "done" only 30% of the user stories, but these user stories embed 80% of the business value, it is better than doing the other 70%.