4 ms·

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 writ

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.
yamtaddle 3y ago
> As a developer
- jansommer 3y ago
  I thought Hacker News was where I could bring my user story jokes :(
Merad 3y ago
Does your app really only have one kind of user (maybe it does, I'm just asking)? My company doesn't get too deep into formal user personas stuff, but we understand that different people use our software to accomplish different goals. For example business owners, corporate accountants, facility managers, and operators all perform different tasks and focus on different information. The purpose of the story jargon is to summarize who needs it, what they need, and why. As SWE's we often don't need to care very much about who or why, but it's important to the product team when they're deciding what to prioritize and explaining to the rest of the business why we're spending time doing this work.

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.

yamtaddle 3y ago

> As a developer

jansommer 3y ago
I thought Hacker News was where I could bring my user story jokes :(

Merad 3y ago

Does your app really only have one kind of user (maybe it does, I'm just asking)? My company doesn't get too deep into formal user personas stuff, but we understand that different people use our software to accomplish different goals. For example business owners, corporate accountants, facility managers, and operators all perform different tasks and focus on different information. The purpose of the story jargon is to summarize who needs it, what they need, and why. As SWE's we often don't need to care very much about who or why, but it's important to the product team when they're deciding what to prioritize and explaining to the rest of the business why we're spending time doing this work.