Ich schätze was, das du nicht schätzt ...

... und das ist ...

zumindest mal ein Dauerbrenner in der agilen Softwareentwicklung.

... zählbar

Oft stehe ich vor Teams und Entwicklern, die in ihrer Vergangenheit nicht die besten Erfahrungen mit dem Schätzen gemacht haben. Noch immer hat aber die Verknüpfung von Implementierung und zeitlichem Aufwand die Vorherrschaft. Meistens versuche ich zunächst, diese Verknüpfung in Frage zu stellen. Und zwar indem ich ihnen anbiete, nicht die Zeit für die Implementierung oder die Komplexität der Umsetzung, sondern einfach nur die Funktionalitäten zu schätzen, die in einer Story stecken. Ohne dabei die Dimension Zeit zu betrachten. Sie sollen die Story so nehmen, wie sie gerade ist - mit allen Unsicherheiten und sie sollen einfach mal betrachten, was nach ihrem Verständnis für den User an Funktionalität geboten wird.

Um es deutlicher zu machen, greife ich als Beispiel eine Story heraus, die in einem der nächsten Sprints umgesetzt werden soll und daher schon relativ detailliert beschrieben und verstanden ist. Dann lasse ich jemanden aus dem Team aufzählen, welche Funktionalität für ihn in der Story steckt und zähle mit den Fingern mit. Dann frage ich die anderen - wenn sie nicht schon selbst eingegriffen haben -, ob sie noch weitere oder weniger sehen. Daraus ergibt sich die erste Diskussion darüber, was das Team als Funktionalität bezeichnet.

... objektiv

Zumindest ist die Schätzung von Funktionalität objektiver als Komplexität und Aufwand. Zugegeben, um zu einer gewissen Objektivität zu kommen, muss das Team sich darauf einigen, was eine Funktionalität ist - zum Beispiel wie detailliert man sie aufsplittet. Das kann etwas dauern, mit der Zeit wird es aber selbstverständlicher und immer ähnlicher. Dieser Prozess ist jedoch „endlich“ und muss nicht für jede Story wieder durchgemacht werden, wie es bei der Diskussion um Aufwände und die Implementierung der Fall ist.Objektiver also aus dem Grund, da wir nicht versuchen etwas vorherzusagen, das man nicht vorhersagen kann.

... unabhängig

Oft wird die Implementierung von Funktionalität durch die Ergebnisse vorheriger Implementierungen einfacher (oder beeinflusst). Diese Auswirkungen spielen jedoch bei der Schätzung mit Funktionalität keine Rolle, denn diese bleibt gleich. Außerdem liefert es ganz nebenbei den besten Anreiz, um bereits Implementiertes wieder zu verwenden.

... vergangenheitsbezogen

Obwohl die Schätzungen erstmal unabhängig von Zeit passieren können und sollten, spielt in die strategische Planung natürlich eine zeitliche Komponente hinein, die sich in der Release-Planung wiederfindet. Mir hat es geholfen, die Releaseplanung nicht als Zukunftsbetrachtung, sondern als Vergangenheitsbetrachtung zu sehen. Dabei sehen wir uns nur an, wieviel Funktionalität das Team in der Vergangenheit geliefert hat. Wir ziehen für unsere Planung also tatsächliche Lieferungen und nicht Schätzungen heran.

... Funktionalität

Zusammengefasst schätzen wir also nicht in die Zukunft gerichtet, sondern lediglich, was wir hier und heute an Funktionalität in einer Story erkennen können. Wir sagen nur voraus, was wir machen - was man später „sehen“ kann. Wir sagen aber nicht voraus, wie lange es dauert, um da hinzukommen und wie wir hinkommen. Bei der zeitlichen Betrachtung vertrauen wir auf das Gesetz der großen Zahl und sagen, dass es mal lange und mal kurz dauert, eine Funktionalität zu implementieren. Daraus bilden wir dann einfach den Durchschnitt und behaupten, dass es auch in der Zukunft im Durchschnitt so lange dauern wird, eine Funktionalität umzusetzen.Und nachdem ich euch jetzt erklärt habe, wie ich meinen Teams das Schätzen erkläre, lasse ich doch einfach mal die Praxis sprechen. Hier ist eine Mail, die ich einem meiner Teams zu diesem Thema geschrieben habe:

Dear Team,

although there were quite some experiments already in this sprint I would like to add one more ;-) Tomorrow in the Estimation Meeting I would like to pick up the idea of estimating functionality instead of time, effort or complexity.BUT independently from what we are doing: I need you to look into the stories beforehand and prepare questions and feedback for XY! Please really do so because the meeting will be a lot more fun if we can discuss all together ;-) and after reading my description below please also try to think in functionality that is in the stories. Write down what you think is the functionality the END USER ACTUALLY GETS (and for the beginning: try to count the functionalities).Concerning the estimation in functionality:We already introduced the shirt-sizes but we can just as well take the numbers for the estimation. Nevertheless keep in mind that the numbers cannot be taken in an absolute manner but rather relatively to each other. Meaning, if you estimate a 13 it does not automatically mean that the stories contain exactly 13 functionalities for the User.Let me give a little example to make clear what I mean by functionality (and yes I know that your domain is not a baby toy by all means but just to get the idea across I will try it like this, ok?)Here are the User Stories:

  • As a baby I want to have a button that makes piiiieeeeeepppp when I press it and changes color from red to green, so that I will laugh out loud.
  • As a baby I want to have a button that makes plooooooooopp when I press it and changes color from red to yellow so that I can be surprised because I expected something else.

Estimating the time would probably mean that you would have to discuss the solution on how to implement it. After this discussion you could try and say: We need about 2 hours to implement it because we think that. While implementing it however, you find out, that you need much longer due to some impediment reason we could not foresee.Also the two user stories are very similar so you could argue and say: Well, if we had already implemented the first story, the second would be doable in 5 minutes. If we have not yet implemented the first one, it would take about 2 hours. So what estimate to pick?From a functionality perspective you would estimate the two stories exactly the same.Lets say we have two functionalities:

  1. the sound
  2. the color change

But one might also argue that we have 4 functionalities:

  1. the button without sound in red
  2. the button in green
  3. the button without sound
  4. the button with sound

Although the second approach of counting might not seem logical I want to make clear that there can be different levels of granularity in estimating functionality. THE TEAM has to figure out a common understanding of what a bucket of lets say xxxs or 1 functionality means or a bucket of L/20 function points means. I call them buckets because as I described above they are not absolute numbers for functionality (as I also did it in the example to clarify) but they are kind of placeholders for a certain amount of functionality. And this amount is always relative to the other stories. So we only say: this s/13 is bigger than the xs/8 but smaller than the l/20 ... it does not mean, that we can exactly count 13 functionalities. If we could always count it to the last bit, we would not have to estimate anymore anyway ;-)Also this approach forces us to actually understand WHAT functionality the product owner wants to get because we want to estimate the functionality the end user gets! Thus this approach can also be more objective because it does not depend on the solution and the implementation.One might now argue, that it still takes different time to implement the Stories as I also pointed out before. In that case we just say that sometimes it takes long to implement and sometimes you can implement very fast due to maybe implementation you did before. Nevertheless - the functionality that is delivered to the customer does not change (if you needed 10 days or only 1 day). So we take the function points delivered in the last 3 sprints and take the average - so we cover also for the cases where it takes long to implement and the ones where it takes little time. And yes, we cannot predict this average of story points for the future. We have to wait 3 sprints until we can actually calculate it!!! But after the three sprints we can take this average and only say - if we assume this average will continue, we can deliver the following functionality at that point of time.. --> Release Plan for the customer!(by the way: questions for the PO in this case could be: Do you want a round button or a square one? Does the button reactivate itself after some time? Can I configure the sound it makes? etc. ... these questions might be too detailed already for an estimation meeting but are great for a sprint planning 1)I hope this helps a little to understand the concept of estimating with function points.Talk to you tomorrow - AND: be prepared!!!Looking forward to it.

Agile Toolbox
Scrum
Product Owner
Schätzen
Scrum-Begriffe
ScrumMaster-Praxistipps
Team
bgloger-redakteur
June 5, 2012

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Warum macht ihr eigentlich kein SAFe?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Transformation

FRAGE: Was kostet eine agile Transformation?

Agile Management
Agile Organization
Agile Toolbox
Leadership
Agiles Lernen

FRAGE: Welche Rolle spielt Training?

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?

Agile Management
Agile Organization
Agile Tools
Agiles Management
Leadership

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Führung

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?

Agile Management
Agile Organization

FRAGE: Warum sollten wir mit borisgloger arbeiten?

Agile Management
Agile Organization
Agiles Management
Transformation

FRAGE: Wie viel kostet eine Beratung und ist es wirklich rentabel bei borisgloger?

Agile Prinzipien
Agile Toolbox
Projektmanagement

The Lie Behind the Parable of the Golf Balls and the Jar

Video
Change
Digitale Transformation
Hardware
Agile Organization

Agile in Industrial Automation: The Digital Transformation of Yokogawa

Versicherung
Neues Arbeiten
Führung
Agile Prinzipien
Kundenfokus

Kundenzentrierte Versicherung: Kann ein agiles Projekt die Organisation retten?

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

Agilität in den Vertrieb bringen – für Versicherer sinnvoll

Versicherung
Agile Prinzipien
Kundenfokus
Agile Toolbox
Produktentwicklung

BizDevOps in der Versicherungsbranche – Wie multidisziplinäre Teams wirklich besetzt sein sollten

Versicherung
Agile Prinzipien
Kundenfokus
Neues Arbeiten
Meetings

Undercover Agile für Versicherer: 5 agile Praktiken für Ihr klassisches IT-Projekt

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

IT-Projekte in der Versicherungsbranche – Das Rennen um die Time-to-Market

Team
Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills

Umgang mit Fehlern & Diversität – Erfolgreiche agile Teams #2

Team
Neues Arbeiten
Agile Toolbox
Produktentwicklung

Das Geheimrezept von High-Performance-Teams

Team
Arbeiten bei borisgloger consulting
Agile Prinzipien
Freiwilligkeit
Selbstorganisation

Konsent und offene Wahl: 2 Prinzipien aus der Soziokratie, die jedes agile Team gebrauchen kann

Team
Neues Arbeiten
Meetings
Social Skills

Der agile Adventkalender

Team
Agile Toolbox
Scrum
ScrumMaster-Praxistipps
Agile Prinzipien

Selbstorganisation der Teams fördern: Ask the team!

Team
Agile Toolbox
Design Thinking

Who Recognizes the Truly Good Ideas?

Team
Agile Organization
Transformation

Pizza Is Not Dead, and Neither Is Agility

Scrum4Schools
Neues Arbeiten
Führung
Life
Social Skills

Trauen wir unseren Kindern mehr zu – auch in der Schule!

Scrum4Schools
Change
Agiles Lernen
Neues Arbeiten
Remote Arbeiten

Eine Scrum4Schools-Projekt-Rückschau mit Physiklehrer Ivan Topic

Scrum4Schools
Mehr Formate
Interview
Nachhaltigkeit

Mit Scrum4Schools dem Weltraum auf der Spur

Scrum4Schools
Change
Agiles Lernen

Scrum4Schools - ein Projekt nimmt Fahrt auf

Scrum4Schools
Agile Schulentwicklung
Agile Toolbox

Technik im Alltag - Scrum4Schools zu Gast in Langenzersdorf

Projektmanagement
Agile Toolbox
Scrum
Scrum-Begriffe
ScrumMaster-Praxistipps

Sprechen Sie Agile? Den klassischen Projektplan in die agile Welt überführen

Projektmanagement
Agiles Management
Agile Toolbox
Scrum
Enterprise Scrum

Das Management in Scrum

Projektmanagement
Change
Digitale Transformation

Agilität in der Logistik oder: Liefern wie Amazon

Projektmanagement
Agile Toolbox
Scrum

Meilensteine und Scrum

Portfoliomanagement
Project management

Too many projects? Portfolio management simplified

Neues Arbeiten
Mehr Formate
Agile Toolbox
Scrum
Scrum Values

Wie agiles Arbeiten die Kommunikation aus der Selbstverständlichkeit holt

Neues Arbeiten
Change
Agiles Lernen
Mehr Formate
Audio

New Learning heute für das New Work von morgen – mit Angelika Weis

Neues Arbeiten
Change
Soziale Innovation

New Work Experience 2019 – ein Erfahrungsbericht

Neues Arbeiten
Audit
Change

Agil im Audit: das Starter-Kit

Neues Arbeiten
Agile Toolbox
Scrum
Scrum4Schools
Agile Prinzipien

Scrum4Schools: Lernen für die Zukunft

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Meetings
Retrospektive

Arbeiten wir uns gesund!

Neues Arbeiten
Agile Toolbox
Scrum
ScrumMaster-Praxistipps

Who should be in (agile) HR?

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Values

Glauben Sie an die Seele Ihrer Firma?

Neues Arbeiten
Agile Toolbox
Scrum
Product Owner
ScrumMaster-Praxistipps

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freiwilliges Teilen von Wissen – Erfolgreiche agile Teams #5

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Doing vs. Being Agile – Erfolgreiche agile Teams #1

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freude bei der Arbeit & Sustainable Pace – Erfolgreiche agile Teams #3

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Anpassungsfähigkeit & schonungslose Offenheit – Erfolgreiche agile Teams #4