User Stories vs Technical User Stories
What is a User Story?
A User Story describes what a user wants and why.
It focuses on value, not implementation.
Think of it as:
“What problem are we solving for the user?”
A typical User Story looks like..
- Identify a user
- Describe what they want
- Explain why it matters
- Keep it non-technical
- Add acceptance criteria (how we know it’s done)
Rule: If a non-developer can’t understand it, it’s probably too technical.
The User Story template
As a
<type of user>
I want<something>
So that<reason / value>
Regular User Story (example)
As a student
I want to submit my assignment online
So that I don’t have to email files to my teacher
Acceptance Criteria (User Story)
Acceptance Criteria define what must be true for the story to be complete.
Acceptance Criteria
- The student can upload a file
- The system confirms successful submission
- The teacher can view the submitted assignment
What is a Technical User Story?
A Technical User Story describes technical work needed to support the system.
It does not represent direct user interaction.
Think of it as:
“What must exist under the hood for user stories to work?”
A typical Technical User Story looks like..
- Describes system behavior
- Focuses on infrastructure, security, or architecture
- Is written for developers
- Supports one or more user stories
- Has clear technical acceptance criteria
Technical User Stories often don’t have a visible “user” — but they are still critical.
Technical User Story template
As a
<system / developer>
I want<technical capability>
So that<system requirement / constraint>
Technical User Story (example)
As the system
I want to validate uploaded file types
So that only safe and supported files are stored
Acceptance Criteria (Technical User Story)
Acceptance Criteria
- Only
.pdfand.docxfiles are accepted - Invalid file types are rejected with an error
- File validation happens before storage
- Errors are logged for debugging
How they work together
User Stories describe what users need
Technical User Stories describe how the system supports it
Key takeaway
If you remove all technical terms and the story still makes sense → it’s a User Story
If removing technical terms breaks the meaning → it’s a Technical User Story
Finished
Back to Overview: Developer Fundamentals