Write user stories not tasks At Linear, we don’t write tasks and think they’re an anti-pattern in product development. We write short and simple user stories t

Write user stories not tasks At Linear, we don’t write tasks and think they’re an anti-pattern in product development. We write short and simple user stories that describe the issue in plain language instead. The point of writing a user story is to communicate a feature. It needs to be clear enough so that the assignee can implement it and also give enough context so that teammates who need to know understand what work is being done. So the goal when writing user stories should be to do this as effectively and quickly as possible. Why user stories are not obsolete User stories evolved over twenty years ago as a way to communicate what a customer wanted into product requirements that a software team could deliver. Fast forward to today and few things have changed about how we build software. Customers are tech-savvy enough to articulate basic product requirements. We haven't developed standards for common features such as shopping carts, todo lists, and notifications so there is no need to explain how they should work. The best product and engineering teams need to understand their users deeply and are familiar with how their product should work. Tasks have become a cargo cult ritual that feels good but wastes a lot of resources and time. They’re a roundabout way to describe features, obscuring the work to be done. User stories are time-consuming to write but tasks can silo engineers into a mechanical role where they code to the technical requirements instead of thinking about the user experience holistically at the product level. One reason user stories are complicated and difficult to scope is because they bring what should be product-level details into the focus of the developer. And frankly, they don’t match how we fail to communicate about software in real conversations. A better way to write user stories Write clear, simple stories that describe features in plain language. Write your own stories. Discuss the user experience at the product and feature level, not the implementation level. Instead of spending time creating tasks, spend it talking to users and thinking through features before writing your stories. ... You get the picture. This article is picking a fight with user stories but the substance of the post remains fundamentally the same when you swap some of the words around. They're ascribing a failure of process to the wrong thing and contributing another entry to the long list of Agile Syllogisms. I think this post would have landed better if they just focussed on what they did in a more descriptive sense. The useful information is clouded by a desire to editorialise it.