3 ms·

Why user stories belong in the garbage

23 points by feross 4y ago

jschveibinz 4y ago
Completely, totally, 100% disagree. A user story is a concept of operation and it is an essential part of requirements analysis. If you throw the user story in the garbage, you can throw your software in the garbage along with it.
- nuclearnice1 4y ago
  You’re quite passionate about it. Could you explain some of your reasons?
  - jschveibinz 4y ago
    Hi, yes I would be happy to provide detail. An important part of any software development project (not prototypes, of course) is the establishment of a solid set of requirements. To do that, an engineer needs to understand the following things: 1. The context of the software. Where does the software “live” in the world? A context diagram is very useful. 2. The major interfaces. What are the channels, formats, data structures, etc. Interface control documents are very helpful tools, as are any number of diagrams depending upon the application. 3. The concept of operation and “user story.” This is a top-level description of what happens when, why, and how to whom? This involves timing, aesthetic, user inputs, safety/security, other usability factors, outputs/results, etc. When you try to describe how people use the software, salient requirements can be discovered. It also helps to create a wireframe that can be shared with the customer to uncover more details or steer the requirements in a different direction. 4. Develop a draft set of requirements. I won’t go into detail, but this is the culmination of the preceding steps. Good luck.
- pleb_nz 4y ago
  I wouldn't go as far as saying your software will end in the garbage. There must be good software that exists that didn't use user stories some now or I'm the past
  - tcmart14 4y ago
    Maybe we need another way to express user stories. So I am sure most all features do have some 'user story,' it is whether or not it is formal or looks like one. Where I work, we don't have 'user stories,' but when I and others on the team work on a ticket, we all essentially create our own user story in our head. The issue with this, does the user story I imagine, sometimes even unknowingly, match up with what was expected without it being implicitly stated? I imagine we all, regardless of how the requirements are laid out, design and code things in our mind with some thought as to the perspective of the user. Sometimes it turns out good, sometimes not so much. Some of us are good at it, some of us are dogshit at it.
x3n0ph3n3 4y ago
Kind of a weird hyperbole, given they recently wrote about how vital user-stories are and how awesome they are at converting them into tasks. [1] 1. https://www.browserlondon.com/blog/2022/05/11/user-story-mapping-changed-how-we-deliver-projects/ https://www.browserlondon.com/blog/2022/05/11/user-story-map...
- havblue 4y ago
  Different authors though. Perhaps in their jira you find.... 1. As a customer I'd like to confirm my opinions about how stories are a waste of time. 2. As a customer I'd like to confirm my opinions about how stories are essential to the requirements discovery and design process.
BLKNSLVR 4y ago
"we tend to think in terms of carrying out tasks" My understanding of User Stories is that there's a story per task, so, to some extent, both itches are scratched with a well thought out set of User Stories.
marcosdumay 4y ago
Oh, well... if you do what the article say, start with an actual story about the user solving a problem, and destroy every useful element until you have a formal scrum ticket... then your stories won't have any useful element. You can throw them away, or you can stop destroying the useful part, and get useful stories to work with. You'll just have to accept that they are not standardized. Really, there two basic ways to specify some software. The algebraic way where you enumerate (ideally independent) capabilities, and the narrative way with stories. Those lead to very different kinds of software, that fit better different problems/users. Throwing one of them away is a great loss.
vannevar 4y ago
>That story was only there because you were yet to break it down into tasks. Not exactly. The story is there to document something you want the software to do, phrased in terms of the value to the user. Once you generate a list of tasks from it, you still need to actually execute the tasks and see if by completing them, you deliver the desired value as expressed in the story. So no, you wouldn't destroy the story once you listed tasks. Once the tasks are done, you still need to circle back and either verify that the goal of the story has been achieved, or that the story is no longer a valid statement about the software.

23 points by feross 4y ago

Completely, totally, 100% disagree. A user story is a concept of operation and it is an essential part of requirements analysis. If you throw the user story in the garbage, you can throw your software in the garbage along with it.

nuclearnice1 4y ago
You’re quite passionate about it. Could you explain some of your reasons?
- jschveibinz 4y ago
  Hi, yes I would be happy to provide detail. An important part of any software development project (not prototypes, of course) is the establishment of a solid set of requirements. To do that, an engineer needs to understand the following things: 1. The context of the software. Where does the software “live” in the world? A context diagram is very useful. 2. The major interfaces. What are the channels, formats, data structures, etc. Interface control documents are very helpful tools, as are any number of diagrams depending upon the application. 3. The concept of operation and “user story.” This is a top-level description of what happens when, why, and how to whom? This involves timing, aesthetic, user inputs, safety/security, other usability factors, outputs/results, etc. When you try to describe how people use the software, salient requirements can be discovered. It also helps to create a wireframe that can be shared with the customer to uncover more details or steer the requirements in a different direction. 4. Develop a draft set of requirements. I won’t go into detail, but this is the culmination of the preceding steps. Good luck.
pleb_nz 4y ago
I wouldn't go as far as saying your software will end in the garbage. There must be good software that exists that didn't use user stories some now or I'm the past
- tcmart14 4y ago
  Maybe we need another way to express user stories. So I am sure most all features do have some 'user story,' it is whether or not it is formal or looks like one. Where I work, we don't have 'user stories,' but when I and others on the team work on a ticket, we all essentially create our own user story in our head. The issue with this, does the user story I imagine, sometimes even unknowingly, match up with what was expected without it being implicitly stated? I imagine we all, regardless of how the requirements are laid out, design and code things in our mind with some thought as to the perspective of the user. Sometimes it turns out good, sometimes not so much. Some of us are good at it, some of us are dogshit at it.

x3n0ph3n3 4y ago

Kind of a weird hyperbole, given they recently wrote about how vital user-stories are and how awesome they are at converting them into tasks. [1] 1. https://www.browserlondon.com/blog/2022/05/11/user-story-mapping-changed-how-we-deliver-projects/ https://www.browserlondon.com/blog/2022/05/11/user-story-map...

havblue 4y ago
Different authors though. Perhaps in their jira you find.... 1. As a customer I'd like to confirm my opinions about how stories are a waste of time. 2. As a customer I'd like to confirm my opinions about how stories are essential to the requirements discovery and design process.

BLKNSLVR 4y ago

"we tend to think in terms of carrying out tasks" My understanding of User Stories is that there's a story per task, so, to some extent, both itches are scratched with a well thought out set of User Stories.

marcosdumay 4y ago

Oh, well... if you do what the article say, start with an actual story about the user solving a problem, and destroy every useful element until you have a formal scrum ticket... then your stories won't have any useful element. You can throw them away, or you can stop destroying the useful part, and get useful stories to work with. You'll just have to accept that they are not standardized. Really, there two basic ways to specify some software. The algebraic way where you enumerate (ideally independent) capabilities, and the narrative way with stories. Those lead to very different kinds of software, that fit better different problems/users. Throwing one of them away is a great loss.

vannevar 4y ago

>That story was only there because you were yet to break it down into tasks. Not exactly. The story is there to document something you want the software to do, phrased in terms of the value to the user. Once you generate a list of tasks from it, you still need to actually execute the tasks and see if by completing them, you deliver the desired value as expressed in the story. So no, you wouldn't destroy the story once you listed tasks. Once the tasks are done, you still need to circle back and either verify that the goal of the story has been achieved, or that the story is no longer a valid statement about the software.