Why technical user stories are bad
You might sometimes come across “technical user stories” when doing agile software development. These are generally a bad idea and should be avoided where possible. This article will explain what technical user stories are, and why technical user stories are bad. And some tips on what to do isntead. It will also cover the rare situations when you do need to use them.
What are technical user stories?
I sometimes see “technical user stories” rear their ugly head. These are user stories that do not have any clear user perspective or value, and are just “technical”.
For example, “call the backend service from the native app”. They describe technical interaction or implementation, rather than behaviour. There is usually no clear user experience flow or value described.
A common callsign of a technical user story is in the “story normal form” description. Instead of “As a user” (or customer or similar), you will find “as a developer” or “as an architect” (or even worse, “as an API” or “as a database” or something).
This is obviously not a good idea! Databases don’t “want things” – they are tool used by people to do things. Find out who those people and what they want to achieve. The database or the API is just an implementation detail. They are a means to an end.
Why technical user stories are bad
Technical user stories are bad because they defeat the fundamental purpose of a user story. Which is to describe the desired behaviour from a user point of view. And to ensure that the value (for some person) is captured.
Nobody gets value from an API talking to a database through an object-relational mapper. People get value from the result of that work: seeing their saved favourites on a website for example. The API talking to the database is a task, it’s a solution. It’s not describing the problem to be solved.
User stories are called “user” for that reason: they describe what the user wants. Not what the developer wants.
The developer wants to get the API connecting to the database. The user wants to see their favourites on a website. The user story describes that.
If you have technical user stories, you are only telling half the story. You are describing an implementation, a solution, a task. But you are not describing a customer problem. And if you can’t, then you don’t know that you are solving one.
Why do teams create technical user stories?
There are three reasons a team might create a technical user story.
They don’t really understand how to write stories
Some teams might be new to writing stories. They might not understand the importance of the word “user” in the phrase “user story”. They might not understand the importance of defining a story in terms of customer value.
Remember, we’re not here to build software for the sake of it. We’re building software to be useful to someone. To provide value to someone. If you can’t define that someone, or that value, don’t build the software. It’s that simple!
These teams often think that a user story is a solution statement or a statement of work. Like a task in a Work Breakdown Structure. That’s not what they are. A user story is a problem statement, not a solution statement. It describes a behavior or state. The tasks and the work involved with the tasks make up the solution statement. Start with the problem: what is the user trying to do or achieve?
I don’t consider this to be an excuse for “technical user stories”.
They have split a big story into smaller stories
Sometimes a team will analyse a story and it will be very large. It might be estimated at 13 or 21 points or more. At this point, the team will usually split it up into various parts. It is a good practice to have smaller stories. A small story is easier to define and test than a large story. Smaller stories will reduce your cycle time. And a smaller cycle time means you deliver value faster, fail faster, learn faster, and improve faster. Stories should be able to be completed in ideally half a sprint or less, but at least within one sprint.
So sometimes when you break a big story into several smaller stories, you end up with one or more “user facing” or “customer facing” stories, and some “technical stories”. The technical user stories need to be delivered to enable the user facing story to be complete and pass testing.
I don’t really consider this to be an excuse for technical user stories either. It is actually OK to have a big user story every now and then. Sometimes it can’t be helped. Don’t make a habit of it. But don’t split it into technical and customer facing stories.
It’s better to split a big story into multiple smaller stories, each of which is a customer facing story, with a technical (i.e. implementation) component underlying it.
But those should be tasks or sub-tasks on those smaller user stories, not separate stories themselves.
They are doing refactoring or non-functional work
Sometimes a team will be doing some refactoring work, or work based around non-functional requirements. Refactoring is changing code without changing its behaviour. It might sound pointless, but it is really important. Developers need to continuously refactor to improve the performance, resilience, testability, etc of their codebase. Refactoring should generally be done as you go. It is part of delivering a story. If you are doing test driven development (TDD), you might be familiar with the Red Green Refactor cycle. So generally I don’t recommend creating stories for refactoring work. It is just a part of delivering a user story.
But sometimes you might be embarking on a big refactoring piece of work. You might be changing the architecture of a system, or changing product or platform. In which case you have a lot of refactoring to do, around functionality that has been there for a while. Then you would have some refactoring user stories.
I would consider this to be an acceptable excuse for technical user stories. But really, they can be reframed as user stories.
“As a user, I want the website’s performance to be improved without affecting its behaviour, so I can continue to use it as I expect it to behave”. It’s a bit clumsy but it shows the idea.
It is almost always better to have stories based around users and their wants, and this is almost nearly always achievable.
What do you think? Have you found examples where technical user stories make sense? Please let me know in the comments!
