When to Write Technical User Stories

By Kawaldeep Singh Chadha, Enterprise Agile Coach and Director of Enterprise Agile Transformation & Coaching

AgiliousProduct DevelopmentWhen to Write Technical User Stories
May 17, 2021 Posted by agilious In Product Development

 

Scrum does not mandate a specific format in which a product backlog item(PBI) is represented. Over time User Story format, which was first introduced by 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 an 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 an 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 prove to 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>

To <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

To 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

To the users of our geolocation service

We need to send the latitude and longitude in the API request

Example 3:

In order to meet the performance SLA

To the applications using our API

We need to support a load of 50 API calls per second without failing

What do you think about the above alternate approach? How have you handled such technical work? Share your experience with us.