On Writing Technical User Story
In my job of being a product manager for a infra platform team, writing user story from a technical, non-end user facing perspective, is a norm (I know, why should a PM write a user story? But long story short, this is how I help the team to be more product-centric). Curious, I then look into how other teams and orgs practice this. And it’s not surprising that I discovered suggestion to avoid this pattern.
But here’s my take.
User story is a form of formalizing end-user facing requirement of a system. It describes how the system should behave to be valuable for a user, without describing in detail how it should be implemented. However, because we’re building a software system, there’s always a technical aspect to a user story that becomes the foundation to it. So how do we deal with it?
There are 2 methods to it that I can see fit:
- Put down technicality as part of a user story’s acceptance criteria. This is the most straightforward and common pattern
- Capture the requirement in form of technical user story
Let’s dive deeper into the second method.
Technical User Story
Technical user story should be used to capture requirement where the end user is a non-human entity. It could be part of the system that needs to behave a certain way in order for the system to be operational. And this can be a separate story altogether from the user story.
For example, a user story could be
As a book seller, I should be able to mark discounted books so they can attract more buyers
Complimentary, but not exclusive to that story, is a technical story that goes
Configuration made to a book store item, should be passed from a message queue, so any changes can be processed async while also being recorded
Again, it captures how the system should work, devoid of an implementation guide, though this time the actor is a system component (book configuration).
Technical User Story in Practice
In practice, technical user story can also be used to capture any requirements or tasks that generate values for the system and developers. For example, refactoring, upgrading components or technical approach, solving technical debts, spikes, etc. But the way this story is written, should capture how it generates value. Why? Because in the end, the team has to decide on prioritizing between all stories in backlog that will end up in comparison between the user stories and technical user stories.
For example, comparing these 2 are not fair:
- As a live streamer, I want to correlate which moment generates reaction from my audience, so I can gauge what are their interest
- Upgrade webrtc server
While comparing these 2 makes more sense
- As a live streamer, I want to correlate which moment generates reaction from my audience, so I can gauge what are their interest
- Implement new webrtc library to prevent closed connection from client to be kept open, to prevent bloated server
Granted, there’s a value in the second technical story, that encapsulates it in form of a user story also makes sense. But the point here is that, devs time aren’t spent time chasing idealist state of a software without a clear value.
The thing that frustrates me when scouring around looking for practice of using technical user story, is the lack of acknowledging that non-human user are still a valid user of the system. There’s a value in writing and capturing technical user story. I see this as an opportunity for every team members to gain better understanding on how a system works, moreover, how to make it maintainable, while adding new capabilities to it.
