16 ms·

User stories? thanks but no

63 points by jandeboevrie 3y ago

psadri 3y ago
I think any software (and possibly product) development process where the starting point is a designer creating mocks / flows in isolation and then handing them over to others to build is doomed to fail. The initial designs, created in isolation from real data, users, what the tech can actually do, etc..., are 99% of the time completely wrong. A better way is to build a minimal working prototype, with whatever actual real data you can get your hands on. Put it in front of actual users and listen to their feedback. Iterate. Once it has settled into its final shape, worry about making it look nice.
- JakeAl 3y ago
  I disagree. The problem started when people doing the flows and storyboards weren't informed or didn't understand the tech side. When waterfall was detailed plans written by people in the know, it was great, but only as long as the engineers (programmers) actually read the design doc. But they stopped doing that and insisted on making it up themselves as they went instead. Good product developers can establish proper blueprints, but a good product developer needs to understand both what the user does AND what the programmer does. Then they can articulate a vision and proper information architecture and functional specifications that make doing the work as simple as following a blueprint/design document. Meanwhile, Agile has become this bloated mess with dedicated roles for everything that a producer or project manager used to do, and the project manager has been reduced to someone just tracking progress instead of informed architects beholden to programmers who refuse to read the well thought out and planned design doc. Before there was agile, there was managing complex design projects by Dubberly. https://www.dubberly.com/articles/managing-complex-design-projects.html https://www.dubberly.com/articles/managing-complex-design-pr... Such a process made sure all the appropriate questions were answered up front most important, what's the actual problem you're trying to solve, not what do you THINK the problem is you're trying to solve. In part I think programmers wanted to be more than just programmers. It's like a construction worker deciding the architect doesn't know what they're doing so they have to be the ones designing the house as they build it. Which may be true if the architect is an artist and not an engineer.
  - chasd00 3y ago
    it takes a lot of professionalism to be an expert in a field and yield to experts in other fields. I think many software devs think they know everything and people are just worn down trying to work with them so you get all these different methodologies. Look at the disdain found on HN for marketing, sales, executives, any part of an organization that is not writing code. In reality, writing the code is maybe 20% of the overall effort in producing a successful software product.
  - psadri 3y ago
    This may have come off the wrong way as a criticism of the people involved vs the process. My point is that iterative design processes tend to work better than waterfall (for new software projects). Architect / construction worker - sure. It is hard to iterate on a building - it has to be more less built as designed and therefore there is a huge onus on the architect to get it right the first time. Software is more malleable, at least at the start.
karaterobot 3y ago
> Now let me summarize and you can decide if we have the same understanding of user stories here: A user story describes a work item. It puts extra emphasis on understanding your users and why satisfying their needs is valuable to them. I don't think a user story should describe a work item. A user story may entail multiple work items, or a single work item may fulfill multiple users stories. A description of a user need is what they are. Their relationship to features is not simple. I agree that most of their value is in deciding if you actually built something to address all your important user stories, but of course you can only really do that by asking users. They are useful for organizing your thinking about what you need to build, though, so I imagine that is how they get conflated with work items or features. I hate personas. At my current company, we have dozens of them, and nobody ever uses them or refers to them. A major effort to create, and time wasted as far as I'm concerned. At a previous company, we had zero personas, but we did have a list of actual, real people who represented the kinds of users we targeted, and we would meet with them to identify new features and validate our designs and prototypes. That was approximately one million times more effective than a list of made-up personas. You cannot hope to capture the complexity of a real person's real needs in an artificial persona.
- hgsgm 3y ago
  Do any of those non-persona real people you know use Burmese on their computer? Are any of them blind?
- chasd00 3y ago
  i've worked with teams that have gone so far in design and even implementation without ever even talking to a user. This is b2b stuff too where user interviews are the most feasible, the actual users are a teams chat/phone call away. I ask teams all the time "have you even talked to the poor souls cursed to use this thing?" and just get blank stares. right out of college I worked at a small independent pharmacy chain as a software developer doing pretty much whatever i wanted (CEO was a good guy and just giving a kid a shot). One of the things my direct boss made me do before i started on any of my ideas was go work in each of our pharmacies for a day, just helping out where i could and observing. I really learned the value of understanding the plight of your users and carried it throughout my career.
leroman 3y ago
I’m not sure im reading well into your criticism about user stories, it sounds like you dislike how they are used in your company. I find user stories critical because they are the lowest common denominator for product/sales/dev/biz etc, everyone gets them, can agree if this functionality will or will not he in release X and pretty much would set expectation correctly between all parties. Additionally, moving down the dev pipeline, once you have wireframes / more specific designs, you can go over the user stories to make sure they are all supported.
jdthedisciple 3y ago
Just one of the many aspects of so called "Requirements Engineering" (which some unfortunate souls have even somehow ended up spending their entire academic career on) which is more or less complete utter BS from start to end if I'm allowed to be clear. I have yet to see a single successful software company that attributed their success in any significant manner to practicing any or all of the mumbo jumbo that is taught in this pseudo-discipline. Reality has taught us over and over again that absolutely nothing beats just doing the damn job! Certainly not circle jerking around the bush with some nonsense User Stories. /rant
- kneebonian 3y ago
  I find it interesting how there are entire disciplines now built around doing exactly what was outlined in the OSS Simple Sabatoge Field Manual https://archive.org/details/SimpleSabotageFieldManual/page/n17/mode/2up https://archive.org/details/SimpleSabotageFieldManual/page/n...
- EddieEngineers 3y ago
  Have you ever written software for critical systems, such as pacemakers or nuclear power stations? Or a role where software integrates with large electrical and mechanical engineering teams? This is fine for some projects but there are other projects where "doing the damn job" is a bad idea or even illegal. Requirements engineering for a startup iterating quickly is pointless but for a well-defined critical system makes more sense.
  - jdthedisciple 3y ago
    While I see your point pointing out potential exceptions, your examples imo sound least suitable for something like "I as user want to sort my notes alphabetically" aka User Stories. Rather, for those critical cases you mention, frameworks like the Waterfall- or V-model, in combination with proper testing, perhaps seem much more called for to ensure compliance, security, and rigidity.
    - EddieEngineers 3y ago
namaria 3y ago
There's too much vertical integration in software development. We need more 'programming at the edge', with professionals who understand a domain well and can write and build software. There's way too much bs in between business needs and building tools to do the jobs that people need to get done. There's way too much complexity involved in building software, and the reason is pretty self evident. Most hardware and most developers are employed by gigantic corporations that extract a lot of rent from the rest of the economy.
- joahua 3y ago
  I like your “programming at the edge” turn of phrase. Centralised IT functions have some bearing here at an org level, not just the wider market. It’s vexed because while I deeply believe business needs would be better met locally, we still want a line of accountability on things like security and availability and data integrity that require a bit of longer term thought. Feature factory thinking certainly exists in bigger centralised teams, the kind that accrete management-speak and overbearing agile processes — but it’s also a false dichotomy to say “just build with the business and nothing of value was lost”.
  - namaria 3y ago
    Isn't the reason we want/need this central accountability precisely the fact that everything software related is an extension of some web based software now a days? It's funny because we preach 'modularity' yet we keep building on this amorphous borg and then we get bitten by its complexity. Not to mention the enterprise drive to streamline everything and destroy silos. Modularity requires redundancy, it's inefficiency that buys us resilience. But forcefully erasing emergent social boundaries on one side and forcing overtly complex structures for the sake of some ill define ideal on software architecture (OOP! microservices!) just nets us the worse of both worlds.
- TobyTheDog123 3y ago
  Well said. I'm currently in a "big tech" public company where I had today: - 2 standups (One Slack-based, one Zoom) - A sprint grooming session - A project retrospective - A product planning meeting - A documentation review meeting In the 3 or so hours I get to work per day (in like 30-45 minute chunks) are mostly spent dealing with updating Jira or asking product teams on clarification. It's a total disaster.
jansommer 3y ago
As a developer, I've always thought user stories were kind of odd: "As a user, i would like to..." But no one writes like that, its user story jargon. Like writing tasks have been formalized in a way where you put yourself in the shoes of the person affected by the change, writing as if you were that person, yet it's (kind of) an order. Not very informal the way the article says they were meant to be.
- elric 3y ago
  The point of using that "formal" jargonized language is that it creates a shared context which builds on top of your shared understanding of the application being built. Using jargon (understood by the whole team) speeds up understanding and reduces the need for verbosity. At least that's the idea.
  - hgsgm 3y ago
    How does "As a user, i would like to..." help?
    - yamtaddle 3y ago
      I'm not a fan of rigid adherence to user story format, but when they're used well one tends to prefer personas or kinds-of-users over "as a user". "As a job seeker, I...", "As an employer, I...", "As a moderator, I..." At their best, they help ensure that when people are adding tasks they have a laser-focus on providing value to people using the system—they force you to think about who it's for and why they might want it (what problem it's solving). This isn't always reasonable, so you sometimes get really stupid user stories at places that insist that all tasks be worded that way.
    - WorldMaker 3y ago
      It tries to put you into the context of thinking as that (type of) user (whether or not you prefer roles, titles, or "personas" in the "as" clause). If you aren't building a feature with some specific type of user in mind, who are you building it for? I think that relates to why I find the "so that" clause far more useful than the "I would like to" clause and almost find them backwards in the formula, but unfortunately, I think they need to be in the order they are in to help reasonably write them (in English). It's too easy to take user requests at face value feature requests and just keep bolting endless features own and maybe not ever properly meet the WHY behind the feature requests and what the user's actual goals are. With all the "so that" clauses filled out in user stories on a board, an Engineer has a much better chance to see the big picture and find ways to solve multiple problems at once, sometimes in elegant ways. Rather than just build a laundry list of features, that may or may not meet user needs, it can help you build a more comprehensive and coordinated approach to building the software. The article points out that engineers often aren't great at knowing the WHY behind a user's request and that's often correct, but that puts cause-and-effect backwards: an Engineer generally shouldn't be writing the "so that" clause, they need that clause for better understanding. Good "so that" clauses come from actual users or at least user advocates (product owners, BAs, support staff, etc). They shouldn't be "optional", the WHY is important to an engineer. The format was designed so that all of it likely should be written by user advocates rather than Engineers. It was designed to be quickly parsed by Engineers, not built by Engineers.
tqi 3y ago
> Relying exclusively on user stories as the source of requirements [...] is not sufficient for the design of solid systems. This narrow focus is one of the main limitations of agile methods. This feels like a strawman - does anyone actually build software this way? I've worked at a place where the a user story isn't considered in the context of the broader product. No one has ever been like "this user story says they want to be able to share their location with a friend" and just slaps a share button on it an calls it a day. In my experience, teams generally think in terms of how that could best fit in with other functionality. Some are certainly less successful than others, but I think that was probably because the teams were bad, not that the stories were bad requirements.
- michaelt 3y ago
  > This feels like a strawman - does anyone actually build software this way? I've seen teams perform this cursed sequence: 1. "As a user, I want my pipes to stop leaking" 2. Replacing the leaking joints and pipes would be very time-consuming, we should produce an MVP using duct tapes and drip-catching buckets an intern empties every day, to confirm that users really want this. If they do, we can redo it properly later. 3. New feature released - pipes stop leaking. Great job everyone. 4. Redo it properly? Our users aren't asking for that, their pipes aren't leaking any more. Interns aren't users.
- imbnwa 3y ago
  >This feels like a strawman - does anyone actually build software this way? Oh yeah, fam.
elric 3y ago
As per usual, whether or not user stories are useful greatly depends on circumstances. Having a team( member) that isn't receptive to using them will certainly diminish any usefulness. I imagine they're not super useful if everyone already knows what's being built and why. But I have found them useful in elaborating context. Why are we building Feature X? Because it makes Story Y possible. Note that user stories do not tell you how to build something (not even really what to build), which seem to be a common fear. They're a tool to help you figure out how (and what) to build. If you don't need the tool, don't use it. Also note that there are other people than software engineers who are interested in what's being built. The client. Sales. End users. Testers. Designers. Technical writers. Etc. All of these role are useful in (many) software projects, and it helps if they're all on the same page ...
sergioisidoro 3y ago
This lacks context of organization size. When you're building a product from the ground up, user stories are super useful to organize and priorize flows and features. They are a super lightweight tool to communicate scope and requirements in small teams. In a large organization or product, using user stories might devolve into chaos, with people using them way beyond their intended and reasonable use.
- bladelessninja2 3y ago
  One thing to add in favor of user stories: they have very broad audience - basically every non-technical person will understand it, which is very useful if the domain is specific and you need an input from regular users.
idopmstuff 3y ago
I feel like people get way too bent out of shape about this kind of thing - user stories are just one way to communicate, and you definitely don't have to use them. I use user stories, technical requirements and visual designs to communicate the needs - which of them I go with depends on the particular context of the product and team. If you work at a place that requires strict adherence to user stories or whatever other bit of methodology you find repugnant, then either try to change the way things are done or quit and find a place that suits you better. I get the impression from some posts on HN that people are toiling away under Agile regimes for years, letting rage build inside them at the indignities of having to estimate/write user stories/whatever else. If you feel that way, consider joining an early stage startup - there isn't strict adherence to much of anything, and you can have a lot of impact on how things are done. You might take a pay cut, but if you hate the day-to-day so much, that's probably worth it. If you won't leave somewhere that you hate working because they're paying you $500k and you don't want to make less money, I don't think you really deserve sympathy anyway.
- mattmanser 3y ago
  I don't really see what this adds to the conversation. It basically boils down to "stop whining and leave". If we can't talk about bad practices, we can't fix them.
  - mangamadaiyan 3y ago
    Corollary: how do you get someone who has partaken of the kool-aid to recognize that a practice involving their pet dogma is bad? In my experience, kool-aid drinkers (regardless of the dogma in question) always go hammer and tongs to defend their position. Any questions as to the goodness of certain dogmatic practices -- or the lack thereof -- are considered to be personal attacks, and summarily dealt with.
    - igetspam 3y ago
      A similar thing can be said about those who see certain ideas as dogmatic. They're so resistant to hearing what the categorize as dogmatic thinking, they often can't hear good ideas. User stories are great, when they make sense and the people reading them and writing them agree on the methodology. Agile is fine for those who like the model but so is (trigger warning: anti patterns being complimented ahead) waterfall. I prefer Kanban but it works well for my team I'm ways agile doesn't. I like it so much, I talk about it. I also like user stories but for a different use case: SLOs. Surprise! I subscribe to the SLOs. Any of the things I just said could be portrayed as one form of dogma or another. It's only a bad thing when people don't align. When people share or at least agree to a methodology, they're great.
jeppester 3y ago
I once built a project management system wherein user stories and tasks were separate entities with no parent-child relationship. If you wanted to connect them you would have to do so through a feature (basically a group of user stories and tasks). The idea was that user stories could be created and grouped into features when speccing a project. Then developers could jump in afterwards and populate the features with actual tasks. The estimation would be done on the tasks rather than the user stories. In the end I didn't really invest the time and ressources to push the idea anywhere, but I still think it's an abstraction worth investigating. That is if it hasn't already been.
- bladelessninja2 3y ago
  I suspect that this approach might not be the best fit for more "fluent" projects as you are unable to reevaluate how things should work until the whole feature is finished, but that's just my wild guess as I've never worked in such setup.
IshKebab 3y ago
I hate them just because they put the most useless information at the front and they just sound so damn whiney. Have you ever seen a list of user storeys? You have to wade your way through "as a user I want to" again and again. And it's in the wrong tense too. Why not just have a "target user" column and a "feature/task" column? Way less obnoxious. Always reminds me of Bill Bailey's speaking as a mother skit.
- bladelessninja2 3y ago
  LOL, just name your stories accordingly and move "as a user I want to" part to description. Haven't you raised that easy-to-fix issue with your team members?
  - IshKebab 3y ago
    Thankfully I've only had to use them once in the past and that was very brief because everyone kind of tacitly agreed to give up on them very quickly. > easy-to-fix issue I see you haven't worked with people! :D
    - bladelessninja2 3y ago
      All we talk about here is how to work with people. I'm sorry, but you strike me as more of a talker than a doer, I hope I'm wrong.
      - IshKebab 3y ago
        You strike me as extremely rude. I hope I'm wrong too.
        bladelessninja2 3y ago
        Yeah, maybe, but I'm not the one who said "I hate them" or "they just sound so damn whiney" and did nothing to change it.
duncan-donuts 3y ago
In my past roles user stories become problematic when you groom and break stuff down. One of the things that I think happens too often is this desire to get every unit of work down to some maximum threshold. In doing so teams start making weird decisions on what the boundaries of something should be and they lose all context on why they’re doing it at all. I think teams should be given the space to say a unit of work is large and complex and something taking a bit of time to work out is ok.
Merad 3y ago
> User stories as requirements seems to be the dominant understanding. Really? Maybe I'm just lucky but I've not seen it yet in my career (10 years). The "as a, I want, so that" text is normally just a summary of who/what/why, and the ticket will include acceptance criteria detailing the changes to be implemented. For features larger than a couple of tickets PO's and PM's will usually keep up with requirements in planning docs that are in Confluence, Google Docs, etc.
skybrian 3y ago
The good thing about this article is asking why there are user stories. Making up an answer isn't so great, though. Better to look at the history. Agile concepts are a reaction to authoritarian companies that do "big design up front," where the programmers were supposed to do what they're told, assuming the people who wrote the requirements knew what they were doing. XP was invented by consultants working on a payroll system at a Detroit auto maker. [1] Often the requirements were bad, resulting in expensive delays or outright project failures. This was meant to be empowering developers in a system where they were at the bottom of the org chart. If those aren't the kinds of problems you have, maybe user stories aren't the solution? A related concept is "access to a user representative" where, if you don't understand a requirement or it's ambiguous, you can ask a domain expert what it means. You shouldn't need to call a meeting to do it, either. Originally this meant physical proximity. Unfortunately this gets watered down a lot. These days we have a lot more communication, often remote. I think there might still be problems getting accurate requirements and with plans changing, though? [1] https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...
- bladelessninja2 3y ago
  A user story is good exercise for less technical people to grasp what developers need to know before starting development: - they are easy to understand as everyone is familiar with concept of telling stories - they enforce a way of thinking about the feature, e.g.: "when click X, then Y happens", which is easily translatable to workflows So I wouldn't be so eager to discard them completely - they are very useful tool, although, not the only tool you should use.
rib3ye 3y ago
> User stories as requirements are bad. User stories as work items might be ok. I think better said: user stories as completion requirements are good. Can the user do it? Then check that off. If the PM comes back and doesn't like how they do it, the PM needs to write better user stories. Full disclosure: I am a PM.
joeyguerra 3y ago
User stories were never requirements. They were the stories people told to uncover problems, and discover solutions.
charles_f 3y ago
I think I reached a point where I get allergic to discussions around capital A-gile "methodologies" about this or that subtrait of one method® that got reused and bastardized by the general public, where most arguments revolve around a combination of semantics, history, and quotation of public figures. It's spelled out in the name of the manifesto. How much more clearer can it be made? The thing is not even two pages long, and yet there are probably less people who read it than there are certified practitioners of this or that process supposedly bringing it to you - where the situation is now about arguing whether some random artifact best conveys a backlog item (won't even get there, you already lost) or requirements (face to face conversation much?). Lost cause.
mcv 3y ago
I think the article is too negative. User stories aren't a magical silver bullet that's going to fix all your problems, but having a good way to write down what the user wants, and forces them to think about it in a structured way, is really helpful. I'm sure everybody here has seen poorly described tickets that don't really make clear what the intention is. Of course "as a $role I want $feature so I can $purpose" is still pretty brief, and I've seen far more detailed templates, but it's good to have something at least. And yes, these stories don't remove the need for more comprehensive requirements and design. They're good for the additions to that, but shouldn't replace them entirely.
deleted 3y ago
[deleted]
goto11 3y ago
User stories makes total sense when you focus on their purpose. A tenet of agile development is to quickly get functionality into the hands of the customer or product owner, so they can provide feedback and get a better understanding of what they want. The user story describes a unit of functionality with can be presented for the product owner. It is described in terms of what the user experience (rather than underlying implementation) because this is what the product owner will evaluate. The article gets lost in definitions and classifications, which is the opposite of agile - that is, the agile which value people over process, not the Big Process agile. User stories are not requirements, because you don't know the requirements before the software is finished, at which point formal requirements are rather useless anyway.
eternityforest 3y ago
I don't like agile stuff much, but I love user stories. They let you start thinking deeply about the UI for a feature before you do anything else. That way, you don't wind up implementing a data model that doesn't map nicely to a UI. Look at old KiCad with it's feedforward pipeline approach full of manual "finish and move to the next tool" compared to other apps. Core functionality and user experience aren't always easy to separate. Starting with user stories lets you design the core of the app in a way that won't constrain the UI or require nasty piles of hacks to get 5he results you want. They also make edge cases more likely to jump out, in a story it's easy to see steps where stuff could go wrong, as opposed to a requirement that isn't like a story, which might be described in a more isolated way and not connected to other features, and not reveal the issues you might have at the interfaces.
than3 3y ago
A forest for the trees article. Inflexible thought, rant, and no real practical alternative. Not really worth a read unless you like to hear people rant, when its clear they are missing the whole point and have misunderstood fundamentals.

63 points by jandeboevrie 3y ago

I think any software (and possibly product) development process where the starting point is a designer creating mocks / flows in isolation and then handing them over to others to build is doomed to fail. The initial designs, created in isolation from real data, users, what the tech can actually do, etc..., are 99% of the time completely wrong. A better way is to build a minimal working prototype, with whatever actual real data you can get your hands on. Put it in front of actual users and listen to their feedback. Iterate. Once it has settled into its final shape, worry about making it look nice.

JakeAl 3y ago
I disagree. The problem started when people doing the flows and storyboards weren't informed or didn't understand the tech side. When waterfall was detailed plans written by people in the know, it was great, but only as long as the engineers (programmers) actually read the design doc. But they stopped doing that and insisted on making it up themselves as they went instead. Good product developers can establish proper blueprints, but a good product developer needs to understand both what the user does AND what the programmer does. Then they can articulate a vision and proper information architecture and functional specifications that make doing the work as simple as following a blueprint/design document. Meanwhile, Agile has become this bloated mess with dedicated roles for everything that a producer or project manager used to do, and the project manager has been reduced to someone just tracking progress instead of informed architects beholden to programmers who refuse to read the well thought out and planned design doc. Before there was agile, there was managing complex design projects by Dubberly. https://www.dubberly.com/articles/managing-complex-design-projects.html https://www.dubberly.com/articles/managing-complex-design-pr... Such a process made sure all the appropriate questions were answered up front most important, what's the actual problem you're trying to solve, not what do you THINK the problem is you're trying to solve. In part I think programmers wanted to be more than just programmers. It's like a construction worker deciding the architect doesn't know what they're doing so they have to be the ones designing the house as they build it. Which may be true if the architect is an artist and not an engineer.
- chasd00 3y ago
  it takes a lot of professionalism to be an expert in a field and yield to experts in other fields. I think many software devs think they know everything and people are just worn down trying to work with them so you get all these different methodologies. Look at the disdain found on HN for marketing, sales, executives, any part of an organization that is not writing code. In reality, writing the code is maybe 20% of the overall effort in producing a successful software product.
- psadri 3y ago
  This may have come off the wrong way as a criticism of the people involved vs the process. My point is that iterative design processes tend to work better than waterfall (for new software projects). Architect / construction worker - sure. It is hard to iterate on a building - it has to be more less built as designed and therefore there is a huge onus on the architect to get it right the first time. Software is more malleable, at least at the start.

karaterobot 3y ago

> Now let me summarize and you can decide if we have the same understanding of user stories here: A user story describes a work item. It puts extra emphasis on understanding your users and why satisfying their needs is valuable to them. I don't think a user story should describe a work item. A user story may entail multiple work items, or a single work item may fulfill multiple users stories. A description of a user need is what they are. Their relationship to features is not simple. I agree that most of their value is in deciding if you actually built something to address all your important user stories, but of course you can only really do that by asking users. They are useful for organizing your thinking about what you need to build, though, so I imagine that is how they get conflated with work items or features. I hate personas. At my current company, we have dozens of them, and nobody ever uses them or refers to them. A major effort to create, and time wasted as far as I'm concerned. At a previous company, we had zero personas, but we did have a list of actual, real people who represented the kinds of users we targeted, and we would meet with them to identify new features and validate our designs and prototypes. That was approximately one million times more effective than a list of made-up personas. You cannot hope to capture the complexity of a real person's real needs in an artificial persona.

hgsgm 3y ago
Do any of those non-persona real people you know use Burmese on their computer? Are any of them blind?
chasd00 3y ago
i've worked with teams that have gone so far in design and even implementation without ever even talking to a user. This is b2b stuff too where user interviews are the most feasible, the actual users are a teams chat/phone call away. I ask teams all the time "have you even talked to the poor souls cursed to use this thing?" and just get blank stares. right out of college I worked at a small independent pharmacy chain as a software developer doing pretty much whatever i wanted (CEO was a good guy and just giving a kid a shot). One of the things my direct boss made me do before i started on any of my ideas was go work in each of our pharmacies for a day, just helping out where i could and observing. I really learned the value of understanding the plight of your users and carried it throughout my career.

leroman 3y ago

I’m not sure im reading well into your criticism about user stories, it sounds like you dislike how they are used in your company. I find user stories critical because they are the lowest common denominator for product/sales/dev/biz etc, everyone gets them, can agree if this functionality will or will not he in release X and pretty much would set expectation correctly between all parties. Additionally, moving down the dev pipeline, once you have wireframes / more specific designs, you can go over the user stories to make sure they are all supported.

jdthedisciple 3y ago

Just one of the many aspects of so called "Requirements Engineering" (which some unfortunate souls have even somehow ended up spending their entire academic career on) which is more or less complete utter BS from start to end if I'm allowed to be clear. I have yet to see a single successful software company that attributed their success in any significant manner to practicing any or all of the mumbo jumbo that is taught in this pseudo-discipline. Reality has taught us over and over again that absolutely nothing beats just doing the damn job! Certainly not circle jerking around the bush with some nonsense User Stories. /rant

kneebonian 3y ago
I find it interesting how there are entire disciplines now built around doing exactly what was outlined in the OSS Simple Sabatoge Field Manual https://archive.org/details/SimpleSabotageFieldManual/page/n17/mode/2up https://archive.org/details/SimpleSabotageFieldManual/page/n...
EddieEngineers 3y ago
Have you ever written software for critical systems, such as pacemakers or nuclear power stations? Or a role where software integrates with large electrical and mechanical engineering teams? This is fine for some projects but there are other projects where "doing the damn job" is a bad idea or even illegal. Requirements engineering for a startup iterating quickly is pointless but for a well-defined critical system makes more sense.
- jdthedisciple 3y ago
  While I see your point pointing out potential exceptions, your examples imo sound least suitable for something like "I as user want to sort my notes alphabetically" aka User Stories. Rather, for those critical cases you mention, frameworks like the Waterfall- or V-model, in combination with proper testing, perhaps seem much more called for to ensure compliance, security, and rigidity.
  - EddieEngineers 3y ago

namaria 3y ago

There's too much vertical integration in software development. We need more 'programming at the edge', with professionals who understand a domain well and can write and build software. There's way too much bs in between business needs and building tools to do the jobs that people need to get done. There's way too much complexity involved in building software, and the reason is pretty self evident. Most hardware and most developers are employed by gigantic corporations that extract a lot of rent from the rest of the economy.

joahua 3y ago
I like your “programming at the edge” turn of phrase. Centralised IT functions have some bearing here at an org level, not just the wider market. It’s vexed because while I deeply believe business needs would be better met locally, we still want a line of accountability on things like security and availability and data integrity that require a bit of longer term thought. Feature factory thinking certainly exists in bigger centralised teams, the kind that accrete management-speak and overbearing agile processes — but it’s also a false dichotomy to say “just build with the business and nothing of value was lost”.
- namaria 3y ago
  Isn't the reason we want/need this central accountability precisely the fact that everything software related is an extension of some web based software now a days? It's funny because we preach 'modularity' yet we keep building on this amorphous borg and then we get bitten by its complexity. Not to mention the enterprise drive to streamline everything and destroy silos. Modularity requires redundancy, it's inefficiency that buys us resilience. But forcefully erasing emergent social boundaries on one side and forcing overtly complex structures for the sake of some ill define ideal on software architecture (OOP! microservices!) just nets us the worse of both worlds.
TobyTheDog123 3y ago
Well said. I'm currently in a "big tech" public company where I had today: - 2 standups (One Slack-based, one Zoom) - A sprint grooming session - A project retrospective - A product planning meeting - A documentation review meeting In the 3 or so hours I get to work per day (in like 30-45 minute chunks) are mostly spent dealing with updating Jira or asking product teams on clarification. It's a total disaster.

jansommer 3y ago

As a developer, I've always thought user stories were kind of odd: "As a user, i would like to..." But no one writes like that, its user story jargon. Like writing tasks have been formalized in a way where you put yourself in the shoes of the person affected by the change, writing as if you were that person, yet it's (kind of) an order. Not very informal the way the article says they were meant to be.

elric 3y ago
The point of using that "formal" jargonized language is that it creates a shared context which builds on top of your shared understanding of the application being built. Using jargon (understood by the whole team) speeds up understanding and reduces the need for verbosity. At least that's the idea.
- hgsgm 3y ago
  How does "As a user, i would like to..." help?
  - yamtaddle 3y ago
    I'm not a fan of rigid adherence to user story format, but when they're used well one tends to prefer personas or kinds-of-users over "as a user". "As a job seeker, I...", "As an employer, I...", "As a moderator, I..." At their best, they help ensure that when people are adding tasks they have a laser-focus on providing value to people using the system—they force you to think about who it's for and why they might want it (what problem it's solving). This isn't always reasonable, so you sometimes get really stupid user stories at places that insist that all tasks be worded that way.
  - WorldMaker 3y ago
    It tries to put you into the context of thinking as that (type of) user (whether or not you prefer roles, titles, or "personas" in the "as" clause). If you aren't building a feature with some specific type of user in mind, who are you building it for? I think that relates to why I find the "so that" clause far more useful than the "I would like to" clause and almost find them backwards in the formula, but unfortunately, I think they need to be in the order they are in to help reasonably write them (in English). It's too easy to take user requests at face value feature requests and just keep bolting endless features own and maybe not ever properly meet the WHY behind the feature requests and what the user's actual goals are. With all the "so that" clauses filled out in user stories on a board, an Engineer has a much better chance to see the big picture and find ways to solve multiple problems at once, sometimes in elegant ways. Rather than just build a laundry list of features, that may or may not meet user needs, it can help you build a more comprehensive and coordinated approach to building the software. The article points out that engineers often aren't great at knowing the WHY behind a user's request and that's often correct, but that puts cause-and-effect backwards: an Engineer generally shouldn't be writing the "so that" clause, they need that clause for better understanding. Good "so that" clauses come from actual users or at least user advocates (product owners, BAs, support staff, etc). They shouldn't be "optional", the WHY is important to an engineer. The format was designed so that all of it likely should be written by user advocates rather than Engineers. It was designed to be quickly parsed by Engineers, not built by Engineers.

tqi 3y ago

> Relying exclusively on user stories as the source of requirements [...] is not sufficient for the design of solid systems. This narrow focus is one of the main limitations of agile methods. This feels like a strawman - does anyone actually build software this way? I've worked at a place where the a user story isn't considered in the context of the broader product. No one has ever been like "this user story says they want to be able to share their location with a friend" and just slaps a share button on it an calls it a day. In my experience, teams generally think in terms of how that could best fit in with other functionality. Some are certainly less successful than others, but I think that was probably because the teams were bad, not that the stories were bad requirements.

michaelt 3y ago
> This feels like a strawman - does anyone actually build software this way? I've seen teams perform this cursed sequence: 1. "As a user, I want my pipes to stop leaking" 2. Replacing the leaking joints and pipes would be very time-consuming, we should produce an MVP using duct tapes and drip-catching buckets an intern empties every day, to confirm that users really want this. If they do, we can redo it properly later. 3. New feature released - pipes stop leaking. Great job everyone. 4. Redo it properly? Our users aren't asking for that, their pipes aren't leaking any more. Interns aren't users.
imbnwa 3y ago
>This feels like a strawman - does anyone actually build software this way? Oh yeah, fam.

elric 3y ago

As per usual, whether or not user stories are useful greatly depends on circumstances. Having a team( member) that isn't receptive to using them will certainly diminish any usefulness. I imagine they're not super useful if everyone already knows what's being built and why. But I have found them useful in elaborating context. Why are we building Feature X? Because it makes Story Y possible. Note that user stories do not tell you how to build something (not even really what to build), which seem to be a common fear. They're a tool to help you figure out how (and what) to build. If you don't need the tool, don't use it. Also note that there are other people than software engineers who are interested in what's being built. The client. Sales. End users. Testers. Designers. Technical writers. Etc. All of these role are useful in (many) software projects, and it helps if they're all on the same page ...

sergioisidoro 3y ago

This lacks context of organization size. When you're building a product from the ground up, user stories are super useful to organize and priorize flows and features. They are a super lightweight tool to communicate scope and requirements in small teams. In a large organization or product, using user stories might devolve into chaos, with people using them way beyond their intended and reasonable use.

bladelessninja2 3y ago
One thing to add in favor of user stories: they have very broad audience - basically every non-technical person will understand it, which is very useful if the domain is specific and you need an input from regular users.

idopmstuff 3y ago

I feel like people get way too bent out of shape about this kind of thing - user stories are just one way to communicate, and you definitely don't have to use them. I use user stories, technical requirements and visual designs to communicate the needs - which of them I go with depends on the particular context of the product and team. If you work at a place that requires strict adherence to user stories or whatever other bit of methodology you find repugnant, then either try to change the way things are done or quit and find a place that suits you better. I get the impression from some posts on HN that people are toiling away under Agile regimes for years, letting rage build inside them at the indignities of having to estimate/write user stories/whatever else. If you feel that way, consider joining an early stage startup - there isn't strict adherence to much of anything, and you can have a lot of impact on how things are done. You might take a pay cut, but if you hate the day-to-day so much, that's probably worth it. If you won't leave somewhere that you hate working because they're paying you $500k and you don't want to make less money, I don't think you really deserve sympathy anyway.

mattmanser 3y ago
I don't really see what this adds to the conversation. It basically boils down to "stop whining and leave". If we can't talk about bad practices, we can't fix them.
- mangamadaiyan 3y ago
  Corollary: how do you get someone who has partaken of the kool-aid to recognize that a practice involving their pet dogma is bad? In my experience, kool-aid drinkers (regardless of the dogma in question) always go hammer and tongs to defend their position. Any questions as to the goodness of certain dogmatic practices -- or the lack thereof -- are considered to be personal attacks, and summarily dealt with.
  - igetspam 3y ago
    A similar thing can be said about those who see certain ideas as dogmatic. They're so resistant to hearing what the categorize as dogmatic thinking, they often can't hear good ideas. User stories are great, when they make sense and the people reading them and writing them agree on the methodology. Agile is fine for those who like the model but so is (trigger warning: anti patterns being complimented ahead) waterfall. I prefer Kanban but it works well for my team I'm ways agile doesn't. I like it so much, I talk about it. I also like user stories but for a different use case: SLOs. Surprise! I subscribe to the SLOs. Any of the things I just said could be portrayed as one form of dogma or another. It's only a bad thing when people don't align. When people share or at least agree to a methodology, they're great.

jeppester 3y ago

I once built a project management system wherein user stories and tasks were separate entities with no parent-child relationship. If you wanted to connect them you would have to do so through a feature (basically a group of user stories and tasks). The idea was that user stories could be created and grouped into features when speccing a project. Then developers could jump in afterwards and populate the features with actual tasks. The estimation would be done on the tasks rather than the user stories. In the end I didn't really invest the time and ressources to push the idea anywhere, but I still think it's an abstraction worth investigating. That is if it hasn't already been.

bladelessninja2 3y ago
I suspect that this approach might not be the best fit for more "fluent" projects as you are unable to reevaluate how things should work until the whole feature is finished, but that's just my wild guess as I've never worked in such setup.

IshKebab 3y ago

I hate them just because they put the most useless information at the front and they just sound so damn whiney. Have you ever seen a list of user storeys? You have to wade your way through "as a user I want to" again and again. And it's in the wrong tense too. Why not just have a "target user" column and a "feature/task" column? Way less obnoxious. Always reminds me of Bill Bailey's speaking as a mother skit.

bladelessninja2 3y ago
LOL, just name your stories accordingly and move "as a user I want to" part to description. Haven't you raised that easy-to-fix issue with your team members?
- IshKebab 3y ago
  Thankfully I've only had to use them once in the past and that was very brief because everyone kind of tacitly agreed to give up on them very quickly. > easy-to-fix issue I see you haven't worked with people! :D
  - bladelessninja2 3y ago
    All we talk about here is how to work with people. I'm sorry, but you strike me as more of a talker than a doer, I hope I'm wrong.
    - IshKebab 3y ago
      You strike me as extremely rude. I hope I'm wrong too.
      - bladelessninja2 3y ago
        Yeah, maybe, but I'm not the one who said "I hate them" or "they just sound so damn whiney" and did nothing to change it.

duncan-donuts 3y ago

In my past roles user stories become problematic when you groom and break stuff down. One of the things that I think happens too often is this desire to get every unit of work down to some maximum threshold. In doing so teams start making weird decisions on what the boundaries of something should be and they lose all context on why they’re doing it at all. I think teams should be given the space to say a unit of work is large and complex and something taking a bit of time to work out is ok.

Merad 3y ago

> User stories as requirements seems to be the dominant understanding. Really? Maybe I'm just lucky but I've not seen it yet in my career (10 years). The "as a, I want, so that" text is normally just a summary of who/what/why, and the ticket will include acceptance criteria detailing the changes to be implemented. For features larger than a couple of tickets PO's and PM's will usually keep up with requirements in planning docs that are in Confluence, Google Docs, etc.

skybrian 3y ago

The good thing about this article is asking why there are user stories. Making up an answer isn't so great, though. Better to look at the history. Agile concepts are a reaction to authoritarian companies that do "big design up front," where the programmers were supposed to do what they're told, assuming the people who wrote the requirements knew what they were doing. XP was invented by consultants working on a payroll system at a Detroit auto maker. [1] Often the requirements were bad, resulting in expensive delays or outright project failures. This was meant to be empowering developers in a system where they were at the bottom of the org chart. If those aren't the kinds of problems you have, maybe user stories aren't the solution? A related concept is "access to a user representative" where, if you don't understand a requirement or it's ambiguous, you can ask a domain expert what it means. You shouldn't need to call a meeting to do it, either. Originally this meant physical proximity. Unfortunately this gets watered down a lot. These days we have a lot more communication, often remote. I think there might still be problems getting accurate requirements and with plans changing, though? [1] https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...

bladelessninja2 3y ago
A user story is good exercise for less technical people to grasp what developers need to know before starting development: - they are easy to understand as everyone is familiar with concept of telling stories - they enforce a way of thinking about the feature, e.g.: "when click X, then Y happens", which is easily translatable to workflows So I wouldn't be so eager to discard them completely - they are very useful tool, although, not the only tool you should use.

rib3ye 3y ago

> User stories as requirements are bad. User stories as work items might be ok. I think better said: user stories as completion requirements are good. Can the user do it? Then check that off. If the PM comes back and doesn't like how they do it, the PM needs to write better user stories. Full disclosure: I am a PM.

joeyguerra 3y ago

User stories were never requirements. They were the stories people told to uncover problems, and discover solutions.

charles_f 3y ago

I think I reached a point where I get allergic to discussions around capital A-gile "methodologies" about this or that subtrait of one method® that got reused and bastardized by the general public, where most arguments revolve around a combination of semantics, history, and quotation of public figures. It's spelled out in the name of the manifesto. How much more clearer can it be made? The thing is not even two pages long, and yet there are probably less people who read it than there are certified practitioners of this or that process supposedly bringing it to you - where the situation is now about arguing whether some random artifact best conveys a backlog item (won't even get there, you already lost) or requirements (face to face conversation much?). Lost cause.

mcv 3y ago

I think the article is too negative. User stories aren't a magical silver bullet that's going to fix all your problems, but having a good way to write down what the user wants, and forces them to think about it in a structured way, is really helpful. I'm sure everybody here has seen poorly described tickets that don't really make clear what the intention is. Of course "as a $role I want $feature so I can $purpose" is still pretty brief, and I've seen far more detailed templates, but it's good to have something at least. And yes, these stories don't remove the need for more comprehensive requirements and design. They're good for the additions to that, but shouldn't replace them entirely.

deleted 3y ago

[deleted]

goto11 3y ago

User stories makes total sense when you focus on their purpose. A tenet of agile development is to quickly get functionality into the hands of the customer or product owner, so they can provide feedback and get a better understanding of what they want. The user story describes a unit of functionality with can be presented for the product owner. It is described in terms of what the user experience (rather than underlying implementation) because this is what the product owner will evaluate. The article gets lost in definitions and classifications, which is the opposite of agile - that is, the agile which value people over process, not the Big Process agile. User stories are not requirements, because you don't know the requirements before the software is finished, at which point formal requirements are rather useless anyway.

eternityforest 3y ago

I don't like agile stuff much, but I love user stories. They let you start thinking deeply about the UI for a feature before you do anything else. That way, you don't wind up implementing a data model that doesn't map nicely to a UI. Look at old KiCad with it's feedforward pipeline approach full of manual "finish and move to the next tool" compared to other apps. Core functionality and user experience aren't always easy to separate. Starting with user stories lets you design the core of the app in a way that won't constrain the UI or require nasty piles of hacks to get 5he results you want. They also make edge cases more likely to jump out, in a story it's easy to see steps where stuff could go wrong, as opposed to a requirement that isn't like a story, which might be described in a more isolated way and not connected to other features, and not reveal the issues you might have at the interfaces.

than3 3y ago

A forest for the trees article. Inflexible thought, rant, and no real practical alternative. Not really worth a read unless you like to hear people rant, when its clear they are missing the whole point and have misunderstood fundamentals.