Should a Product Backlog Have Technical User Stories?

Scrum does not mandate a specific format in which a product backlog item (PBI) is represented. Over time, the User Story format, which was first introduced by the Extreme Programming (XP) framework in 1998, has become very popular and has more or less become a de facto standard in which PBI’s are written. The User Story format as put forth by XP is:

As a <type of user>

I want to <some goal>

So that <some reason>

User Stories are designed to invoke conversations between the team members to create a shared understanding of the user’s need, and more details are added as the functionality is built.

The User Story format makes perfect sense when your product has a User Interface (UI) and there is a direct interaction with a user. Almost all PBIs can be represented as a user story in this case. There may be situations where some aspects of the product are non-functional or technical in nature and cannot be expressed as a user story. However, this should be rare (less than 5%).

If your product does not have a UI, which will be the case if your product is an Application Programming Interface (API), middleware or some backend system. Using the User Story format in this case does not make as much sense, or at best will be very difficult and challenging.

In these situations, there is a better and more appropriate format to express the PBI. This format is:

In order to <deliver benefit/value>

For <these people/system>

We need <this function>

Below are a few examples of technical stories.

Example 1:

In order to keep track of all the transactions with our service

For the Solution Integrators

We need to generate a unique identifier for each transaction

Example 2:

In order to provide an API for a location finder

For the users of our geolocation service