4 ms·

> nothing beats just doing the damn job! Okay, but you have to define what the job is. That's what user stories are for. You don't have to use them (there are

> nothing beats just doing the damn job! Okay, but you have to define what the job is. That's what user stories are for. You don't have to use them (there are many other ways of scoping and defining work), but you literally can't just do the damn job unless there is a definition of what the job is. > 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. There are lots of multi-billion dollar companies that use user stories. I guess they don't attribute their success to it by proclaiming that user stories are amazing on earnings calls, but if you're suggesting that there are no successful companies that use Agile and related methodologies, you're demonstrably wrong.

jdthedisciple 3y ago
I truly would like to see just one successful software company that started out by creating User Stories vs just simply creating and building their vision. Sure, plenty started incorporating all sorts of stuff much much later on. I haven't seen it be a significant initial contributor for the eventual success. Especially not vs simply doing. The vision defines what needs to be done better than anything else ever could. That said, some of the companies with the most budget out there (cough something from Redmond cough) probably use these sorts of modern "techniques" all the times yet manage to regularly fail utterly when it comes to basic usability of their products.
jofer 3y ago
I have yet to see a single user story that actually gives any correct details of what the user wants or is doing, though. They're invariably written by product managers who have never been in the users shoes and have absolutely zero understanding of what the product is or what the users do. The engineers building a product have typically actually been in the users shoes. The product managers almost never have. When I start seeing user stories that aren't actively harmful, I might feel differently. As it is, the first thing you should do as an engineer is throw away the user story or management's description of the problem and go straight to the actual user feedback. User stories are like watching a fish try to describe a bicycle....
- xcv123 3y ago
  > I have yet to see a single user story that actually gives any correct details of what the user wants or is doing, though You're working in soft domains. Typically a business would have very specific hard requirements for processing financial transactions and related information. If you work in banking or insurance the requirements need to be clearly defined by the business.
  - jofer 3y ago
    No. I'm working in very technical domains. Management has zero understanding or background in anything. Engineers have a minimum of a PhD in the field + at least a decade of experience in the field + software engineering experience. We've been in our users shoes. Management has not and can't even understand the industry.
    - xcv123 3y ago
      You will have a different experience in something like insurance, where requirements come from external integrated systems, third parties, actuaries, government regulations, business analysts etc. Not clueless managers.
      - TheNewsIsHere 3y ago
        I feel for the above commenter. I cannot relate to their experiences as fulsomely. Within my past several roles I have always had a really good experience with engineering, requirements gathering, and how those disciplines are executed by stakeholders, including management. It’s fair enough to say that having worked at a cryptography company where the CEO was a mathematician is probably fairly rare, but I don’t think that this being an exception is an indictment on the various methods used to go from ideation to implementation. Edit to say: user stories in particular are as good or as bad as those involved in creating them are skilled and understanding of what is being requested, what is needed, etc. In my prior company we had an entire design team who took care of the UI/UX, and decoupled that (largely) from logic, implementation, platforms etc.
sdeframond 3y ago
> you literally can't just do the damn job unless there is a definition of what the job is. Sometimes the best way of knowing what the job is is to do something quick, gather feedback and iterate until it is good enough. In other words, to know what the job is you might actually have to do the damn job!
- chasd00 3y ago
  > gather feedback that list, in narrative form, is a list of user stories. Even more so If you talk to users before you start and get their input and insight on the most useful thing to build.
  - marcosdumay 3y ago
    What the GP is describing is absolutely not user stories. For a start, if he talked to the users before he started, he would get something completely different.
- kmoser 3y ago
  > Sometimes the best way of knowing what the job is is to do something quick And that "something" you're doing quick is based on...user stories! Unless you're making up something entirely in your head, with the idea that "if we build it they will come," i.e. a solution in search of a problem.
marcosdumay 3y ago
> you have to define what the job is Technically, you don't. Defining the work and then doing it is an overwhelmingly popular preference, but plenty of people do different and, AFAIK, it doesn't impact their success rate. > That's what user stories are for And yes, there are many other ways to do that besides user stories. "X was created to solve Y" is not by itself a good reason to use X when you need to solve Y. Whether X is any good is important too. In fact, functionality description (the thing that user stories was created to fight against) seems to normally lead to much better systems than user-story based designs. > There are lots of multi-billion dollar companies that use user stories. And well, this stopped being relevant when user stories became a fad pushed by more than 99% of the managers.
- Supermancho 3y ago
  For sake of clarity, "you" here means someone or some group. >> > you have to define what the job is > Technically, you don't. Technically, yes, "you" do. Most developers do not solely decide what they get paid for. This sentiment is as absurd as my example: I'll bring a toilet in tomorrow and call the serial processing job done because I delivered (without looking at any sort of work definition).
  - marcosdumay 3y ago
    Oh, your "you" here implies a manager-managed submission relation! Yeah, you can't have that without one of the parties defining the work. Again, that is a widely popular way for people to arrange themselves, but it's not obligatory. There are many people that do not work that way.

jdthedisciple 3y ago

I truly would like to see just one successful software company that started out by creating User Stories vs just simply creating and building their vision. Sure, plenty started incorporating all sorts of stuff much much later on. I haven't seen it be a significant initial contributor for the eventual success. Especially not vs simply doing. The vision defines what needs to be done better than anything else ever could. That said, some of the companies with the most budget out there (cough something from Redmond cough) probably use these sorts of modern "techniques" all the times yet manage to regularly fail utterly when it comes to basic usability of their products.

jofer 3y ago

I have yet to see a single user story that actually gives any correct details of what the user wants or is doing, though. They're invariably written by product managers who have never been in the users shoes and have absolutely zero understanding of what the product is or what the users do. The engineers building a product have typically actually been in the users shoes. The product managers almost never have. When I start seeing user stories that aren't actively harmful, I might feel differently. As it is, the first thing you should do as an engineer is throw away the user story or management's description of the problem and go straight to the actual user feedback. User stories are like watching a fish try to describe a bicycle....

xcv123 3y ago
> I have yet to see a single user story that actually gives any correct details of what the user wants or is doing, though You're working in soft domains. Typically a business would have very specific hard requirements for processing financial transactions and related information. If you work in banking or insurance the requirements need to be clearly defined by the business.
- jofer 3y ago
  No. I'm working in very technical domains. Management has zero understanding or background in anything. Engineers have a minimum of a PhD in the field + at least a decade of experience in the field + software engineering experience. We've been in our users shoes. Management has not and can't even understand the industry.
  - xcv123 3y ago
    You will have a different experience in something like insurance, where requirements come from external integrated systems, third parties, actuaries, government regulations, business analysts etc. Not clueless managers.
    - TheNewsIsHere 3y ago
      I feel for the above commenter. I cannot relate to their experiences as fulsomely. Within my past several roles I have always had a really good experience with engineering, requirements gathering, and how those disciplines are executed by stakeholders, including management. It’s fair enough to say that having worked at a cryptography company where the CEO was a mathematician is probably fairly rare, but I don’t think that this being an exception is an indictment on the various methods used to go from ideation to implementation. Edit to say: user stories in particular are as good or as bad as those involved in creating them are skilled and understanding of what is being requested, what is needed, etc. In my prior company we had an entire design team who took care of the UI/UX, and decoupled that (largely) from logic, implementation, platforms etc.

sdeframond 3y ago

> you literally can't just do the damn job unless there is a definition of what the job is. Sometimes the best way of knowing what the job is is to do something quick, gather feedback and iterate until it is good enough. In other words, to know what the job is you might actually have to do the damn job!

chasd00 3y ago
> gather feedback that list, in narrative form, is a list of user stories. Even more so If you talk to users before you start and get their input and insight on the most useful thing to build.
- marcosdumay 3y ago
  What the GP is describing is absolutely not user stories. For a start, if he talked to the users before he started, he would get something completely different.
kmoser 3y ago
> Sometimes the best way of knowing what the job is is to do something quick And that "something" you're doing quick is based on...user stories! Unless you're making up something entirely in your head, with the idea that "if we build it they will come," i.e. a solution in search of a problem.

marcosdumay 3y ago

> you have to define what the job is Technically, you don't. Defining the work and then doing it is an overwhelmingly popular preference, but plenty of people do different and, AFAIK, it doesn't impact their success rate. > That's what user stories are for And yes, there are many other ways to do that besides user stories. "X was created to solve Y" is not by itself a good reason to use X when you need to solve Y. Whether X is any good is important too. In fact, functionality description (the thing that user stories was created to fight against) seems to normally lead to much better systems than user-story based designs. > There are lots of multi-billion dollar companies that use user stories. And well, this stopped being relevant when user stories became a fad pushed by more than 99% of the managers.

Supermancho 3y ago
For sake of clarity, "you" here means someone or some group. >> > you have to define what the job is > Technically, you don't. Technically, yes, "you" do. Most developers do not solely decide what they get paid for. This sentiment is as absurd as my example: I'll bring a toilet in tomorrow and call the serial processing job done because I delivered (without looking at any sort of work definition).
- marcosdumay 3y ago
  Oh, your "you" here implies a manager-managed submission relation! Yeah, you can't have that without one of the parties defining the work. Again, that is a widely popular way for people to arrange themselves, but it's not obligatory. There are many people that do not work that way.