Read on Twitter
At @linear_app, we don’t write user stories. They’re unnecessary and slow down the team.
I also always found them very weird to write and read. It’s like the tasks are in ancient Greek instead of English that everyone can understand. Wonder if other people felt this way?
More
I also always found them very weird to write and read. It’s like the tasks are in ancient Greek instead of English that everyone can understand. Wonder if other people felt this way?
More
User stories are a roundabout way to describe a todo. It would be ridiculous to write your todos this way. “As a human, I need to go to the store in order to have food to eat”. You would never write that. Instead: “Get groceries” and list items to buy.
Or imagine trying to build a rocket with user stories. Behind the “Fly me up the gravity well and not blow me up” user story, there is thousands of technical parts systems that needs to be built and considered. User stories is the wrong kind of abstraction for most tasks.
I think user stories came to be ~20 years ago when engineers and users operated in very low context environment. Nether engineers or users really knew how to describe software. Everything was new. User stories were a language to describe functionality
Today, most good engineering teams operated in high context environments, having a lot of knowledge of the product, market, users and existing solutions and patterns. Both engineers and users also have experience using other products and can visualize solutions.
Instead of writing user stories, at @linear_app we write the tasks in simple way. The title should be short but as descriptive as possible. Description can contain additional information. The task should be actionable and have a deliverable (e.g. code, design or document).
The purpose of a task is plan, and remember what to focus on and act on it. It should be clear how to take action, talk about it, triage and and scan in lists and boards. Unlike with user stories, where each time to you have encode and decode to understand what the story is about
Also common pattern we hear from top startups is that they encourage their people do create their own tasks. This creates more high context environment.
Teams should own the how, and not single taskmaster who create issues for everyone else. https://twitter.com/linear_app/status/1338941374893199360
Teams should own the how, and not single taskmaster who create issues for everyone else. https://twitter.com/linear_app/status/1338941374893199360
Ditching user stories doesn’t mean you should forget about the user. You can collect feedback on features. Write product and project briefs. Describe user needs and value there
Just forget user story encoding and write what needs to get done https://linear.app/method/write-tasks-not-user-stories
Just forget user story encoding and write what needs to get done https://linear.app/method/write-tasks-not-user-stories
