> 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 a lot of things have changed about how we build software. Customers are tech-savvy enough to articulate basic product requirements.<p>I'm jealous of your customers if that’s true for you. But, IME, not only are customers no better at spontaneously producing requirements than they were 20 years ago, IT organizations—<i>especially</i> ones that have notionally embraced “Agile” methods—are much worse at eliciting requirements, or even understanding what they should look like. It’s like the entire understanding of requirements was the baby thrown out with the bathwater of big upfront design.<p>And this article on tasks instead of stories is a further step down that path of losing knowledge. Yes, once you have requirements, you need to task out the implementation. But tasks don’t replace description of requirements, whether in the form of stories or any other form.
> 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.<p>A few problems with this:<p>1. User Stories, as described by Mike Cohn or in some other textbook description, are supposed to be light weight. They are time consuming to write only in so far it takes time to understand what is the 1-2 sentence summary of the thing to be done.<p>2. User stories are intentionally ambiguous to avoid "siloing engineers into a mechanical role where they code to the issue requirements." A User story says, "When you're done writing code, here's the thing that needs to happen. Tasks are useful when there isn't much ambiguity, but I've certainly worked with developers who take the approach "I wrote the database table task, I did the Java code task, I did the JavaScript front end task, I'm done" without sanity checking if everything works together.<p>3. A User Story literally says what the User Experience should be like. Even if that were the wrong approach, I fail to understand how telling developers "Here's what the User Experience should be like and why they want to do that thing" prevents them from thinking about the user.<p>Overall, even if there's some truth here, this is a silly article. Stating "User stories evolved over twenty years ago" isn't helpful, because tasks evolved even longer ago. User stories are supposed to be "short and simple" and "describe the task in plain language." I'm really left wondering if the things they call "tasks" and "user stories" are the same thing that I use for those terms.
I find, after creating software for 14 years, that 1) clients don't know what they want, 2) they can't communicate what they want 3) describing features is difficult it doesn't matter if we call it a story or an issue, 4) something will always change
I've started writing a one-sentence description of what we'll do to demo the feature to stakeholders. I find that this approach tends to leave much less room for confusion than the user story formula.<p>Also, "Can I fit it into one reasonable sentence?" is a surprisingly good litmus test for whether the task is right-sized. Not necessarily in terms of implementation effort, but in terms of scope.<p>User stories might be good for a Scrum product owner who's trying to juggle a more nebulous set of ideas in a product backlog. By the time the work's ready to hand off to the dev team, though, you should be able to come up with a something more concrete and concise.
>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.<p>I found it kind of ironic they lead with this, then proceed to describe their issue tracker using a long winding story that took a while to actually get to the point and before I could even figure out what this actually was.
Hard disagree. User stories are a great pithy way to describe a high-level need with a supporting reason. They usually take only a few minutes to write quite a few and in group exercises we've been able to generate many very rapidly.<p>The task/ticket however (and work to be done) is separate and derived from the user story. This can dive into architecture choices, _why_ this solution and _why not_ that one, specific implementation details and steps to achieve those.<p>Both types have their pros and cons and work best when used together because they serve different people and different goals.<p>Don't write something off just because you saw a post make it to HN p.1 - try things out for yourself and decide based on _your_ team and _your_ needs.
I don't think the problem is "user stories" vs "tasks" vs "issues".<p>I think people have taken the (relatively simple) concepts from agile (as described in the Manifesto) and surrounded it with a lot of (often rigid) process and structure.<p>Many people really like the comfort that comes from knowing what the process/structure is. And problem-solving tends to add to an existing solution rather than examine whether something should be removed (per recent HN post).<p>Consequently, rules/structure/process grow "unbounded".<p>Fighting this tendency is hard because it goes against the easy, "natural" path.
What's always missing with any kind of feature work is context. User stories can kind of provide some context ("why"), but the best method I've found is to write expectations--it will do X, Y, and Z. Then have some kind of call to confirm understanding and provide context.<p>A lot of companies skip or eliminate this last step because PMs are busy, developers are introverts, some other excuse. But the fact is, spec-only development very rarely achieves the desired outcome because the developer can't or isn't allowed/trusted to see the forest from the trees.
The main issue I've found with Agile is that in the two iterations I've seen (one BigGovCorp, one late-stage startup), the team ends up with a situation analogous to audience members directing a movie. You can collect a list of audience requirements (explosions, romance, Chris Hemsworth, a string quartet, Garfield) and then your devs can string them all together into a single package that <i>technically</i> works, but there's no rhyme or reason or predictable trend of what the software <i>is</i>.<p>Furthermore, as other commenters are mentioning, once you start focusing on your ticket system, developers feel "done" when the tickets are done, rather when they believe that what they've implemented is actually a functional, conceptually consistent piece of software.<p>I don't think there's any solution except "get the right people and then try a bunch of crap and stick with whatever gets the best results measured against the goals of leadership."
AD: I call BS... There is a fundamental difference between functional requirements and the tasks required to implement them. Note there are NO examples in that article, and I bet you it's because it was hard to think of context free tasks... because context is everything and thats what your functional requirements provide your tasks.<p>User stories capture functional requirements:<p>```<p>As a restaurant guest<p>I want to consume food<p>Because I am hungry<p>Scenario: Guest is provided with menu when they are sat at their table<p><pre><code> Given there is a free table
When I am sat at my table
Then I should be given a menu
</code></pre>
```<p>This is BDD style, I don't really care what you think of BDD it covers what I need to make the point... First of all context is king, there should be NO scenarios here that do not satisfy the guest being hungry, thats scope creep. Equally there is NOTHING here about HOW you implement this, it does not mention who gives the menu, what the menu contains, how it looks or anything about the rest of the restaurant. Why is that the case? Because we are at a level of abstraction that is talking about delivering value, not about the quality of what we deliver. You can only deliver value to users so we can only talk about users and their experiences. Now as for tasks, they are derived from these functional requirements, they connect what currently IS to what needs to be, e.g. if we currently give guests a menu when they enter the door, thats what IS, now we need to go about creating a task to change that to when the guest sits down, thats the task and it is a poignant task because it's derived from our functional requirements, there is no room for scope creep here.<p>Please do not write context free tasks, you'll run yourself into the ground in scope creep, because you're detached from what matters. That's why user stories are important... but most people don't write user stories correctly, they treat them like a task template and forget the value delivering aspect and all the context that goes with it.
Whether this works on not depends on the team structure and person writing the task. Yes, directly writing tasks is more efficient, but it requires the person writing the task to deeply understand the perspectives of <i>both</i> the development team and the people using the software.<p>Most teams don't have (enough of) these types of people. It is fairly common for teams to primarily consist of people who are non-engineer users, and technical engineers who aren't intimately familiar with the users' jobs. If your team has these groups working together, and these lines aren't clearly drawn, then you often get people overstepping their bounds: users demanding technical changes that make no technical sense, and developers building features that make no business sense.<p>And this isn't a fault of the users or developers, it's a failing of process. People inherently want to decrease friction in their requests and their interactions. Five completely reasonable requests over the course of a year might add up to a horrible application -- not because the user or the developer was at fault for making a bad decision, but because the entirety of the goal was never communicated. This is what user stories do: force different groups to fully communicate.
I'm glad to see this article is eliciting in others the same reaction I had when reading it. I'm a huge fan of Linear and use it for our company, but this article just has so much hand-waving going on it's staggering. Where is a single example? They claim that user stories are outdated, inefficient, not valuable and yet show no alternative to the seriously difficult problem of engineering tasks missing context and purpose, especially after a certain amount of time has passed. I can't count the number of times I've fired off a one-line task thinking "This is fine. I'll remember what I need to do when I get to it" only to, after a few weeks, go "WTF?".<p>The part about writing your own tasks is also strange. So my coworker finds an issue and instead of just writing the task out with context, explanation and direction, he has to... explain it to me in some medium... then I go do it? Really?..<p>I feel like this article was written as some kind of SEO "let's just get people here looking at our product" kind of thing. I can't believe this was written by someone who actually writes software.<p>(edited for typos)
<i>"The best product and engineering teams understand their users deeply and are familiar with how their product should work."</i><p>Surely not. And ironically, it seems the writer is describing a developer-centric view, not a user-centric one.
As a reader of your website I'd like to see an example of this horrible antipattern or an example that discourages the developer from thinking about the hollistic work to be done.
More humility, please.<p>They found a way it works for their team and claim that they solved software development. Well on their team page they have 9 super experienced members backed by big investors.<p>Get a product where you have 3 teams with 30 developers (probably 20 juniors and 10mid/senior), 15 testers and and 20 business analysts/customer people, maybe 2 or 3 product owners to keep it somewhat tidy. Keep it lean because you have pressure from above to cut spending as much as you can, because there are no angel investors above you dropping helicopter money. Have an approach that will work in that environment. Then take it and implement in 2 more companies with the same result, then you can write what is and what is not obsolete in software development.
>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. ... Customers are tech-savvy enough to articulate basic product requirements<p>HA. Sure. 20 years ago Customers were dum-dums, but today Customers are tech-savvy.<p>>issue should describe a task with a clear, defined outcome.<p>The point of user-stories is that the implementing developer also has a brain and is able to contribute to the solution. So a user story is supposed to communicate the problem the customer is trying to solve so that the specific solution can be derived collaboratively. Nothing is worse than writing a task to turn a developer into an automaton.
> The project owner writes specs and gathers feedback until we feel like we have the right approach. Only then do we start writing code.<p>Uhm, it is hard to say what is the "right approach". I personally prefer a more iterative approach. You draft an architecture to solve the issue at hand and you iterate based on new requirements.<p>I generally don't like when a group of "owners/architects" close themselves in the basement to come up with a bunch of specs and documents describing : THE SOLUTION
Isn't this more a problem that backlog items have become to-do lists of tasks rather than a list if desired features? Or another way of saying that the article assumes coherent features should be moved away from developers, and developers are just task executors. You could keep user stories on the backlog as product features and then give developers the job of organizing their tasks to achieve those features.
Write user stories not tasks<p>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.<p>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.<p>Why user stories are not obsolete<p>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.<p>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.<p>A better way to write user stories<p>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.<p>...<p>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.<p>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.
I often write both, sometimes just a task, sometimes a story, sometimes I'll only include a sketch. The claim that User Stories are "dead" or an "anti-pattern" is silly. What's an anti-pattern is to claim that your communication method works best for all projects, teams, contexts and times.<p>In my experience, for new teams the more detail the better. For these teams I often write both. They need the additional information and it helps them get in the head of the customer. Sometimes for well gelled teams switching to a new context I'll do this. Or, sometimes for well gelled teams working on a problem space where there's alot of nuance in the solution, or maybe it's a departure from the norm and there's a good reason, I'll write both. Sometimes I'll be in planning and realize that the team is missing the picture and I'll write a user story on the spot and things will click.<p>For teams working on a space they know well sometimes just a description of the issue is enough. They know how to fix it and why. I dont need to waste my time or theirs writing contrived examples. They probably dont need a task to tell them what to do. They can figure it out.<p>Also, this is BS:<p>1)Customers are tech-savvy enough to articulate basic product requirements.
-- Some (few) customers are savvy enough to communicate basic requirements but I've rarely met a customer who can articulate edge cases and considers their needs in context of the system- either technically, economically, or socially. Part of the value of a user story is the abstraction.<p>2)We’ve developed standards for common features such as shopping carts, todo lists, and notifications so there is no need to explain how they should work.<p>-- No we haven't! Go checkout at 5 different stores and tell me how many are using an identical cart. Even stores that use identical cart providers have widely varying carts because business and user needs are different and everyone is playing with their own ways to optimize conversion. I think it might be difficult to find a better example of something that's not fully standardized than a cart.<p>3)The best product and engineering teams understand their users deeply and are familiar with how their product should work.<p>-- "Best" is operative here... the best teams I've worked with like user stories because they frame the requirements in the context of the user instead of assuming the PM/PdM/Whoever has the "correct" solution.
This hits close to home. I always found user stories as a convoluted nonsense, especially when abstracted away to be as general as possible. When I feel that something is useless it doesn't go well, especially when I have use to it. I never complained to anyone because that is part of the job but why? I was told it was a common language and that's that. To me tasks make a whole lot of sense. Even the name 'user story' sounds dumb, I wonder why they had to call it like that. But that's my own opinion and I should keep it to myself if I want to be employed.
In my team, we write a half page of user stories up front so we're all clear one who the user is. After that it's all iterative prototypes that get shown to clients. They're a lot better at giving feedback when they have something in front of them. The resulting problems they have get turned into issues, e.g. "we need the default for value foo to be bar". Dunno if it's a process following best practices, but the team's growing so it's worked well so far.
Welcome to another episode of "X, as per my definition of X, is bad - Let's talk about Y, which is another definition of X, but not the one I disagree with".
Seems like a huge downplay of a genuine UX technique with long-attested success. User stories help keep in mind other/all perspectives in a way tasks don’t. Also the direct copy of Apple M1 chip shadow/gradient on the homepage is a bit gauche.