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.