Im Scrum werden größere Aufgaben in User Stories zerlegt. Diese User Stories werden anschließend geschätzt. Dabei wird nicht die Zeit geschätzt welche das Team für die Aufgabe benötigt. Stattdessen wird die Komplexität der User Story geschätzt. Story Points sind dabei die abstrakte Einheit um Komplexität bzw. die Größe der Story einschätzen zu können. Nun ist es für Menschen kompliziert akkurat zu schätzen wo der Komplexitätswert einer User Story liegt. Was Menschen besser können ist es eine User Story mit einer anderen User Story zu vergleichen. Man definiert bzw. nutzt bestehende User Stories als Referenz, welche man bereits bearbeitet hat und weißt ihnen einen Referenzwert zu. Als Werte nutzt man dabei eine modifizierte Fibonaci-Reihe nach dem Schema:
1, 2, 3, 5, 8, 13, 20, 40, 100
Mit Hilfe der Referenz-Stories können nun die neuen User Stories bzw. ihre Komplexität geschätzt werden. Bei der Planung schaut man wie viele Story Points man im letzten Sprint erfolgreich bearbeitet hat und nutzt diese Zahl für die neue Planung. Neben den Referenz-Stories, welche zur Einschätzung der Komplexität dienen, wird während der Planung meist auch Planning Poker gespielt. Kern des Prozesses ist dabei das verdeckte Schätzen der Komplexität. Nachdem die Karten aufgedeckt wurde, erklären die beiden Mitspieler mit der niedrigsten und der höchsten Karte ihre Einschätzung. Anschließend wird das ganze wiederholt, bis das Team eine fundierte Einschätzung der Komplexität vorliegen hat.
Für den Product Owner ist es natürlich wichtig zu wissen, wie viel Zeit die eingeschätzten Tickets benötigen. Dazu bedient man sich des Velocity-Faktors. Dieser ergibt sich aus dem was das Team in den letzten Sprints an Story Points abgearbeitet hat. Wenn das Team in acht Stunden z.B. durchschnittlich 4,3 Story Points abarbeitet, kann der Product Owner die benötigte Zeit abschätzen.