Determining Customer Story Complexity

As we are using customer stories as an indicator of team productivity, we figure out that each story contribution is different according to its complexity. But how do we quantify a customer story complexity?

Complexity Grade

To start with we need to adopt a grade or a scale that allows us to represent customer story complexity as a numeric value that can be used in a mathematical model.

Let us use a scale from 1 to 10 where the simplest story holds a complexity value of 1 and the most complex story holds the value of 10.

Function Point Breakdown

Next, we need to breakdown a customer story into some quantifiable units that allows us to build the complexity value based on efforts required to build and implement a story.

One of the good mechanisms that can be used at an early stage of product backlog building and sprint planning is the concept of function points (FPs).

According to Wikipedia the?function point?is a "unit of measurement" to express the amount of business functionality an information system (as a product) provides to a user.

So, we need to breakdown a customer story to business functionality units and use those FPs as basis for customer story complexity determination.

Function point analysis may seem a bit sophisticated process that follows an ISO standard, but it provides to be an efficient method assisting project effort estimation.

In an agile based software development project, we tend to use a more simplified form of function point analysis that allows us to break down a customer story into areas such as inputs, outputs, inquiries, files, and interfaces.

You need to figure out the number of inputs a customer story declares to be used when developing the information technology component that serves the story. For example, in a cheque clearing system for a scanning customer story front, back, and UV images are three inputs required for a scanning function to work. MICR data, cheque date, amount, and beneficiary name are other four inputs. This means that in such a customer story has declared seven inputs.

Continue with the same cheque scan story we can tell that the outputs include a record representing all data within a scanned cheque along with three objects representing the scanned images. This means we have four outputs.

Following a customer story it looks that the workflow shall go through five stages each requires a single inquiry, assuming that the record and the three images are files then we have four files, looking deeper at the process we can tell that there will be four interfaces: one with the cheque scanner, two other interfaces with the core banking system to inquire customer information and post an outward transaction, and one interface with the central clearing system to post an outward item for clearing.

Summing up those 7 inputs, 4 outputs, 5 inquiries, 4 files, and 3 interfaces we can tell that we have 23 function points representing this customer story.

A full FP analysis requires determination of complexity factors for each function point so that we can tell the final quantified FP value; but for our simplified mathematical model we will consider the number of function points as an indicator of customer story complexity (CSC) rounded between 1 and 10 by dividing the number of FPs by a value that represents the maximum number of digits in a customer story that has the largest number of function points, assuming that is a 2 digits number then we will divide the FP count by 10 and the complexity of our story becomes CSC = 2.3.

Now we can use that in our mathematical model.