# Linear App Authors - Write Tasks Not User Stories - Linear Method (Highlights)  ## Metadata **Cover**:: https://readwise-assets.s3.amazonaws.com/static/images/article3.5c705a01b476.png **Source**:: #from/readwise **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[Linear App Authors]] **Full Title**:: Write Tasks Not User Stories - Linear Method **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **URL**:: [linear.app](https://linear.app/method/write-tasks-not-user-stories?cmdid=PK4MOZLQ241BJM) **Host**:: [[linear.app]] **Highlighted**:: [[2021-07-27]] **Created**:: [[2022-09-26]] ## Highlights - At Linear, we don’t write user stories and think they’re an anti-pattern in product development. We write short and simple issues that describe the task in plain language instead. - The point of writing an issue is to communicate a task. It needs to be clear enough so that the assignee can perform it and also give enough context so that teammates who need to know understand what work is being done. - Customers are tech-savvy enough to articulate basic product requirements. - User stories are time-consuming to write and read and can silo engineers into a mechanical role where they code to the issue requirements instead of thinking about the user experience holistically at the product level. ### A better way to write issues - Describe concrete tasks or problems - You can create placeholder issues in these instances to break down later (e.g. Explore design) or frame it as a deliverable (e.g. Write project spec). - Write clearly and directly - When sharing a feature request or bug report, quote user feedback directly instead of summarizing it. - Write your own issues - It’s faster and easier for the person who understands how to do the work to write issues describing it. - Keep user experience discussions at the product level