Teams, die User Stories üblicherweise in Storypoints abschätzen die auf Funktionalität statt auf Aufwand beruhen, kommen bei der Abschätzung von Stories ins Strudeln, die keinen funktionalen Charakter haben.
Das könnten z.B. längere Analysestories sein, oder das Austauschen eines Quellsystems gegen ein anderes.
Zu überlegen ist dabei, ob diese Stories denn überhaupt Punkte bekommen sollten. Oder ob Analysetätigkeiten einfach die Velocity senken. Wenn über die Velocity der fachliche Fortschritt gemessen werden soll, erscheint das passender. Wenn es Gründe für eine Abschätzung gibt, kann man die Frage stellen: Um welchen Wert würde die Velocity im Sprint absinken?
Bei technisch motivierten Stories, wie z.B. der Austausch eines Quellsystems gegen ein anderes, kann man die Funktionsänderung an der Schnittstelle abschätzen. In dem Fall ist es nicht die Funktion, die der User sieht, sondern der Entwickler bzw. das eigene System. Vielleicht lässt sich auch feststellen, welche Funktionen für den User gleich bleiben müssen und das sind dann die abzuschätzenden Funktionen. Das mag auf den ersten Blick zu viel erscheinen, andererseits müssen diese Funktionen getestet werden und je nach Änderung des Quellsystems müssen auch einige Businessobjekte oder gar Abläufe geändert werden. Das Risiko des Unbekannten ist mit einer höheren Abschätzung besser abgedeckt, als mit einer geringen.