> 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.
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—especially 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.
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.
> [Project teams will] understand the user experience intuitively, so you don’t need to clarify it at the task level.
My god, the hours I've spent under both engineer and PM hats because of misalignment about what the user experience is supposed to be! "The task said 'enable color selection', not that the old color should be un-selected."
This philosophy seems to be leaning really hard on the assumption that your team is re-implementing well-worn patterns, but shouldn't items that are so well-worn as to require no explanation or context just get subsumed into higher-level stories?
I've pointed out before that the job description of "Systems Analyst" seems to have disappeared i.e. someone who's job it was to understand and describe requirements. I agree with you about the baby and the bathwater, though to be fair there was often quite a bit of bathwater.
You didn't mention what it has been replaced with. And if your company doesn't have this role then I would definitely see why you are complaining.
What I mean is the Product Owner as defined by Scrum. Either as a 'hat' worn by someone whose official title in the HR system is Systems Analyst or actually as a title in said system even. At my last place they were called "Business Analyst" on paper.
If you don't have a PO, then you are not playing the game of Scrum.
It will come back with more regulatory pressure, but under a different name, because startups tend to reinvent the wheels and give funny names to the old ideas. I won’t be surprised if someone will come up with a new RUP soon, because compliance will dictate the need for formal requirements, RTMs and QA processes.
> I've pointed out before that the job description of "Systems Analyst" seems to have disappeared i.e. someone who's job it was to understand and describe requirements.
If the role of "systems analyst" died, it's murderer was the legion of arrogant developers who, armed with their weaponized Dunning-Kruger blend and personal belief they are the perennial 10x, criticize systems analyst and architects and principal engineers and any role whatsoever that involves designing and specifying system architectures as being always and invariably played by incompetent fools who are lesser beings than the flawless and perfect dev and never do anything right. Repeated often enough, this flavor of anti-intellectualism, which advocates that a constant churn of ad-hoc solutions to the problems they created for themselves, is naturally better than any attempt at a rational design based on requirements.
Both their one-sided blame story and yours are likely to be just as wrong.
There's no question that many people in systems analyst or architecture roles, that are divorced from the details of actual development, came up with flawed designs that were more work to implement and produced worse results. That was one of the antipatterns that Agile was a reaction to.
The problem with those roles is that they tended to be embedded in a waterfall architecture model, where system development involved some variety of requirements -> analysis, architecture & design -> development. The amount of interaction and iteration between those phases was often much lower than it should have been. There are many factors involved here. Simply having different teams for those functions is one of them, since that tends to reduce interaction between the phases.
I think requirements and design documents are necessary for any project of a certain size. In my organization we try to do this for a project that will take a few Sprints. A Sprint is 2 weeks. The requirements and tech design don't have to be perfect, and they can be updated, as time goes on. If updates are signficant, then we point that out, and adjust deadlines.
The nice thing about this is you have a document that describes what we built, and another document which describes how we built it, at the end of the short project. We scope these projects so they can fit into a quarter. If it's longer than quarter, we try to break it down by certain milestones.
I also don't like User Stories, maybe it's just how they are set up in JIRA, but once you have the tech design, it's pretty easy to break it down into tasks. This mostly works for my company.
> A Sprint is 2 weeks. The requirements and tech design don't have to be perfect, and they can be updated, as time goes on.
> This mostly works for my company.
What is working for your company (and others) is: delivering software FAST. Which is good and all, but I think it’s important to highlight this because sometimes, some people prefer to deliver maintainable software in a paced way (no sprints, but marathons... I hate the analogy but hey).
there are certainly some subset of customers who can write effective product requirements for any product, but certainly not all or perhaps even most.
the point of users stories is not to lose sight of the origins of a domain traversal problem (from customer/problem domain to product/solution domain). jumping straight to writing tasks assumes high intimacy with the problem domain and the solution domain, which few people possess. the best product managers have both of those, and still are humble enough to regularly test their assumptions by writing user stories first backed up by quantifiable customer experience.
> 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 few problems with this:
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.
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.
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.
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 agree with you, but feel compelled to point out the (slightly) insightful part is "Customers are tech-savvy enough to articulate basic product requirements."
There are consulting projects where the customer knows what they need and can spec it. They are similar to "we need a brick wall built here; use a core of breeze blocks and clad it with brick up to four foot high". You can write the needed tasks easily and get to work.
As you point out, user stories (which far precede 20 years ago and come from the advertising world) are a step above (or before) that, to cover "Oh, people need to be able to look in through this fence; if it's solid then it can't be higher than five feet, maybe less".
This essay would have been better as a short, "don't cargo cult things like user stories when you're already past the point"...but instead they cargo-cult it by inverting the sense and advocating throwing them away.
Product marketers and advertisers used to (and as far as I know still do) write "biographies" of target customers to help decide what messages to send, what the packaging should look like, how and where it should appear in the supermarket etc.
They'd look like, "Jane, 35, has an undergraduate degree in a technical field, and is married with two kids. She exercises a few times a month but wishes she could do it more..." Then they say, "So would Jane be drawn to this color or is it too opinionated for her?"
This isn't what a user story is. This sounds like a persona, which is a thing in product management. But it is not the same thing as a user story at all.
A user story is something like "Customers want to see the items most recently added to the shop". Or, in Connextra form:
As a customer
I want to see the items most recently added to the shop
So that i can stay abreast of developments in fashion
Freud and Jung actually became close friends over a decade before Jung coined his archetypes so that might be how Bernard got exposed to the ideas, even though (IIRC) Freud and Jung had a falling out later. Bernard would have been in his 20s or so
We organise our tasks into a hierarchy where the outer Feature is user-oriented, the next level down (Product backlog item) are the developer-oriented detail of the user feature and the next level are tasks that break down the work needed to compete the PBIs, in 1-8 hour chunks.
Features can parent features, so what we end up with is whatever amount of detail is necessary to capture the user stories and other requirements, under which are the work items the developers care about.
I think this separation provides a decent balance between producing the features the users need while still allowing developers to focus on the actual technical work required.
Yes, this makes good sense. We do it this way too. Stakeholders and executives can easily grok the top level items, described in terms of their UX and business value, and then those are broken down into tasks that product/tech/design folks can execute on.
Subtask[1] is one tool that makes this really easy and fluid, because you can break down everything into parts and the parts into parts, etc etc.
In my experience the problem is that when written as you describe them - user stories represent features and are rarely, if ever, granular enough that they represent a "thin vertical slice" of functionality - as scrum likes to call it. I've always felt this was something scrum did a poor job of addressing.
I have found that using user story format for epics or for features, and then further breaking those down into tasks seems to work quite well. Although as far as I'm aware there is no concept of a "task" in scrum. Task seems to be a Jira concept.
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
After creating software for almost 30 years, this is still true.
But...it's not their fault. Asking anyone to precisely describe a complex system that is subject to change will have the same problem(s).
This is why Agile[0] was such a breath of fresh air. And Iterative Prototyping, MVP's, all that. It's massively easier and quicker to slap something together, put it in front of a customer and ask them what's wrong with it, than it is to ask them what they want in the first place.
In my experience a quick "it should do this" is good enough to get that going, and then iterate from there.
[0]Actual Agile. As in the Manifesto. Not this Scrum bullshit.
It is interesting to watch scrumm. I have seen it broken a few times now. Every single time it started off just fine. Then someone decides the process was more important instead of the intent. Then everyone just went along with it. Even worse someone knows they 'still dont like it' but keep tweaking it but making it worse instead of saying 'yeah that did not work atall'. Or my favorite is someone blows in and finds out you have been skipping one ritual (because it was low value to your team). Your team is then declared 'broken'. It is like there is some flaw in scrumm that allows for anti patterns.
> But...it's not their fault. Asking anyone to precisely describe a complex system that is subject to change will have the same problem(s).
Yes. In the same breath someone might denigrate users for not knowing what they want and also explain about how they can't accurately timeline their personal coding project where they are the only user and developer.
Designing any complex system is hard. Asking users to take part in that design process means asking them to do something hard (or at least that's hard if done well, and hard to tell you aren't doing well unless you put in that effort you didn't know you had to). Complaining about bad user requirements as fine, but truthfully it should be done in a way that's self deprecating...
> I find, after creating software for 14 years, that 1) clients don't know what they want (..)
I've logged in just to point out this fact, and to call out how the author of this anti-user stories rant is completely clueless and out of touch with the reality of developing software.
The whole point of user stories is to not only specify an objective target but also a concrete definition of done, in spite of the clients' inherent ambiguity and flexibility, and very often also contradicting notions inherent to their asks.
User stories report intent and context along with the goal. User stories adds information that helps developers help the customer. If you remove the out-of-band information, you are creating a process that is a throwback to the bad old days of waterfall, where saying that it's the client's fault that the devs built the exact opposite of what the clients were expecting.
All which was old is eventually new again, and in the case of "linear method" the novelty is not having a clue of what you need to do to meet customer's demands and expectations.
Exactly right. One thing I often tell younger developers is... 80% of developing software is figuring out exactly what you want to build." Usually, the actual act of building it (i.e. writing the code) is fairly trivial.
So very true. I usually ask what business outcome they are looking for and then tell them how I'm going to deliver that for them. Saves a lot of hassle.
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.
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.
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.
"Let the user import legacy data", though, is not a one-sentence description of a feature demo. "Import a transaction list file in version 1.0 of the format and show that it loads all entries," would be more like it.
It is also going to lead to wildly different implementations developer to developer unless they have a really solid understanding of the project. And given how frequently we turn over, that rarely exists.
I usually don't really know anything about how the code I write will be used in practice.
You can't stop at the user story. Actually that sentence is not a user story at all.
It just says 'user' which is way too generic.
It's missing the "why" which can inform the developer a lot about the actual AC for this story both when discussing the story prior to starting estimation and later when it turns out that some AC is unclear or missing.
The 'standard' format of 'As a <type of user> I want <do X> so that <I can do/get/see etc Y>'
Of course it's very possible to write utterly bad user stories in this format too and to write good ones that do not follow it slavishly.
So why do these users want to import legacy data and who is this user?
Let's say this is an import that only ab admin can do.
As an Admin I can import legacy data.
Better. Let's say our system only has one level of admin so that this is actually completely clear and not ambiguous.
So why does he want to do this? Since we don't know the context you had in mind I will invent one. Let's say that this is an on premise (not cloud/SaaS) issue tracking system that and it has an export feature and we want to be able to import from the old legacy format that has since changed. People routinely use this export/import to create a data dump for backuo purposes and the problem is that only the same version of our software can read them.
As an Admin I want to import legacy data so that I can use old data dumps from previous versions in a newer version instance.
Much better. Let's add some imaginary AC:
* should be able to read version 0.8 to 1.3 data formats (no need for <= 0.7 as those were EOL'd 2 years ago)
* add to both current master as well as the release branches for 1.4 through 1.7
* user should be able to import any size file (we've routinely seen customers with dumps in the 2gb+ range)
* show a progress indicator on screen while the import is running
These could be some initial AC that can now be discussed with the team. The team might tell you that 0.8 had a real dumb quirk and if we could skip implementing that it would save us weeks of implementation and testing time. Also support it on 1.4 would suck because of that big refactoring that happened in 1.5 and it would basically mean writing the legacy import twice instead of cherry picking it with minimal conflicts.
And so on and so forth. Depending on how you work and what roles your org has there might be a design attached for the progress indicator and such or you're expected to whip something up. Or you tell the PO that he should check the current feature set because we already have a progress indicator there and this is just about adding new (old) file format support! And then he tells you that the indicator was only added in 1.6 which suddenly makes this a hidden backport of other features and you might split the story into more than one or say 'screw it' and remove that AC (you get the indicator in versions where it exists but no backporting).
>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.
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.
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.
Both types have their pros and cons and work best when used together because they serve different people and different goals.
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".
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.
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).
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.
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.
I totally agree. Developers are intelligent people who know a lot more about how to best execute a ticket than the people writing tickets. They however know a lot less about the context than the people writing tickets. Converting developers into task executing machines seems like you lose a lot of the advantages of having intelligent people in the loop.
I don’t really care what it is called and what format it comes with, but understanding the why of a task is crucial to me. There is a good chance that I over- or under-engineer otherwise. And understanding it I can often come up with simpler more maintainable results than if someone imposes the solution on me without talking about the problem.
Also spec-only development is horribly boring in my opinion.
AD: Agreed! I'd look into BDD as an exploration and specification process (it's not just a testing methodology!), it taps into the goals of your users and features that satisfy those goals. See my comment below for a crude example.
So far all of the comments here are just dances around how we perform business analysis. It is a role, is it a process, will we split it into pieces in our workflow, will we do it along with a prototype?
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 technically works, but there's no rhyme or reason or predictable trend of what the software is.
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.
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.
User stories capture functional requirements:
```
As a restaurant guest
I want to consume food
Because I am hungry
Scenario: Guest is provided with menu when they are sat at their table
Given there is a free table
When I am sat at my table
Then I should be given a menu
```
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.
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.
> There is a fundamental difference between functional requirements and the tasks required to implement them.
Tasks that don't honor the 'why' of the work can make someone look productive when they are not (or indeed, when they are being destructive).
I see the same thing in 5 Why's analysis. There's always one faction that wants to come up with an inactionable 5th Why. It is remarkably easy to steer such discussions to whatever agenda you are pushing.
As has been said elsewhere, beware that zealot on your team who keeps on with the whys until the user gives up and screams, in tears, “because I don’t want to die alone!”
I think the insight here is that if you're asking your user you aren't going to get the answers you want. This is why survey writing is so hard, because people can't just explain themselves on the spot.
I don't mean to pick on your example... but it's absolutely not true that I go to a restaurant because I'm hungry.
There are other ways I can and would sate my hunger if that was my genuine motivation. For me to go to a restaurant, it does have to provide food, but that is not sufficient, since I can get cheaper/more convenient food elsewhere.
A restaurant has to offer something other than just food, or I won't go at all.
AD: Sorry you got bogged down in the details. Would you like me to put together a more thorough example? That one I wrote in 2 minutes.
To clarify I picked /some/ value for the restaurant guest, but we could negotiate what the /true/ value is. I go to restaurants when I'm hungry and I'm sure others do, but you're right there are other reasons why you might go, but that doesn't detract from my point being made.
I commented this because I find it does relate to your point - in my view, you have identified a false motivation/incorrect user story.
By my understanding, this is exactly what the parent article is identifying as potentially damaging.
Quote from the article: "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."
So let's negotiate the true value? How else are you going to know if you're delivering technology thats useful?
You said there are other reasons, what are those reason? I've gone to restaurants to meet friends... and ultimately we all eat to satisfy our hunger.
My point is that tasks are derived from functional requirements, they aren't context free, and if you make them context free then we're just doing what ever we want? To analogise, why do you have relationships in databases and indexes? An index is a flat map to speed up lookups on known queries, you don't get at the meat of your query in the index, the meat of what you want is in the row and it's relationships. You have an object graph for a reason, and yeah it was the hard part, but it's what makes a model useful.
... and to counter the quote... What's the point of your users experience if it's not to get them to where they are deriving value?
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 both the development team and the people using the software.
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.
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?".
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?..
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.
As a self taught developer who only works solo I'd agree. Tasks is exactly how I think. I've never found a use for stories. However, I can imagine how they are helpful to teams who individually do not have the holistic bigger picture or may not have the context of knowing the end goal/UX component. For me, the tasks are brush strokes of the bigger picture and spelling it out in story form just to break it down to tasks is duplicative.
That said, sometimes my tasks are bigger strokes like "Add edit profile functionality" where it's obvious I'll have to touch the backend, database, frontend, etc. I don't have to break this into tasks.
>I can imagine how they are helpful to teams who individually do not have the holistic bigger picture or may not have the context of knowing the end goal/UX component.
Yes. Exactly.
Because you're a solo developer - so either you're a hobbyist (so you know what you want), or you're talking with your customers. And as a solo developer there isn't really a need for any process or structure or any special productivity tools. You can just use notepad to organize your work.
>For me, the tasks are brush strokes of the bigger picture and spelling it out in story form just to break it down to tasks is duplicative.
Imagine a scenario where there is a middle-mam between you and the customer. What if that middle-man gave you task to put a button that does X on a toolbar in a web-app, and imagine you have no idea what problems or needs the customer experienced that necessitated this button. But you're a professional, so you do that. Then you get a task that says to remove the button and turn the action into a right-click menu option ... so you do that. Then you get a task that says the right-click menu option needs to be also accessible by a long-press left-click and the context options need to be bigger. Then you get a task that states the options menu when opened needs to centered under the point of long-press/right-click (instead of to the left) .... I can go on, but tell me honestly, at what point do you as a professional developer just stop and ask the middle-man either for a meeting with a customer, or just have them tell you what the customer is trying to do. Because clearly there is some type of "XY problem"[1] happening here. The customer and the middle-man are trying to solve something and they are spinning in circles and you cannot really contribute to the solution because you have no idea what they are trying to solve. Was the need for 'long-press' option added as some sort accessibility functionality or as a way to make the app compatible with mobile devices? Was the need to change the location of the context menu because of a preference, or was it because on certain devices the context menu was truncated by the edge of the screen ... etc. etc.
That's the point of stories. They provide context to the developer so they can have a big picture in mind and be part of solving this problem. If you know that your web-app is meant to be used by seniors with compromised dexterity who will be primarily be using a mouse, you'll think of ways to make it easier to navigate the app versus if the app is for teenagers on their phones. You'll be able to collaborate with the middle-man (and customer) to bounce ideas of each other. As a developer, you're not an automaton even if IBM wants you to be.
No kidding. If you write software for specialized domains, you may not be able to get developers with in-depth knowledge of the space (e.g. writing software for Radiologists).
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.
Well, why? And what characteristics you expect the example to have so you are satisfied with it? Please state them all up-front so he has the freedom to misinterpret them and not accept any correction after the fact.
I think I know what he is talking about. My only problem with the article is that the thing he said he uses is more aptly named "user story" too. Those are just not broken "Scrum user stories".
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.
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
HA. Sure. 20 years ago Customers were dum-dums, but today Customers are tech-savvy.
>issue should describe a task with a clear, defined outcome.
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.
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.
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
Yeah, the whole point of stories was to get away from "Software Creationism"
the belief that with a sufficently detailed specification, a normally talented group of engineers can magic a perfect solution without any customer interaction.
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.
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.
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.
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.
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.
Also, this is BS:
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.
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.
-- 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.
3)The best product and engineering teams understand their users deeply and are familiar with how their product should work.
-- "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.
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—especially 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.
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.