Using Story Points Together with ISBSG Benchmarking Data

It is well known that agile teams use Story Points in their Planning Sprints for sizing work effort. Story Points are not a metrics but use Fibonacci categories to distinguish small (3) from medium (5) to large (8) to extra-large (13) effort size. When assigning user stories to developers per sprint, this is just good enough.

Story Points are specific to a team, and even specific to the point in time. After knowing the domain better, the work effort to implement something might become lower, or in contrary, higher because the complexity initially was underestimated.

Nevertheless, management typically needs a little bit more, and different, information for budgeting product maintenance and future development. A responsible manager cannot run blindly into the adventure of digitalization; she or he needs some financial guidance for knowing whether the organization can afford offering a product or not.

Function points counting specialists are used to look at an application as a whole; they distinguish between new functionality added, functionality changed, and functionality removed from an application. They draw a boundary around a system and declare the inside as the system being assessed for its functional size.

Unfortunately, this approach is not compatible with the VIM and the GUM. The International Vocabulary of Metrology (known as the VIM) and the Guide to the Expression of Uncertainty in Measurement (GUM) are the international standards for metrics, issued by the Bureau International des Poids et Mesures. A typical requirement for a metric is that you can measure parts, and then derive from those measures the size of the whole. Boundaries make no sense for a metric.

But boundaries are anyway missing in Agile Development. Agile developers perform sprints, one to many, as needed, and after each sprint deliver functionality, enriching some already existing product. The functional size of the whole product is less important than the size of functionality added. Thus, when measuring software in agile development, measurement must cover sprints. Or even smaller: user stories, or story cards that describe the part of a user story fitting into a sprint.

Now, the lucky punch is that exactly these story cards is what development teams measure with story points. All what is needed is to collect functional size together with story points for each story card.

Obviously, since story points refer to work effort, not size, there are story cards that have no functional size but considerably many story points. This is solving another problem in estimating: how to measure non-functional requirements and taking them into consideration for total development cost estimates. Thus, translating story points to functional size must take non-functional work effort into account.

A sample story cards, referring to a Helpdesk User Story, might look as follows (from IT Confidence conference, Firenze 2015):

In this case, 8 Story Points correspond to 9 Function Points according ISO 19761 COSMIC. With a statistically relevant collection of such story cards, predicting functional size based on story points is as easy as it is the other way around. Still, such conversion is team-specific, and domain-specific. Using ISO 20926 IFPUG works as well, as recently presented at the 3rd Evento Metrico 2017 in Caserta, Italy.

More information about using Story Points with the ISBSG database can be found in the author’s book “Managing Complexity”, ISBN 978-3-8325-4406-5, Logos Press Berlin 2016.

Dr. Thomas Fehlmann, swissICT; ISBSG vice-president.