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

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.