3 ms·

How does "As a user, i would like to..." help?

by hgsgm 3y ago

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.

How does "As a user, i would like to..." help?

by hgsgm 3y ago

How does "As a user, i would like to..." help?

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.