When I see something like this, I think the appropriate response is that with requirements, there is no "best way" for every circumstance. If you have an inter

When I see something like this, I think the appropriate response is that with requirements, there is no "best way" for every circumstance. If you have an internal user or small set of internal users, you are likely better off spending time with them, building the smallest thing that can solve their immediate problem, and keep building from there. User stories are great here because your requirements gathering is asking the people doing the job. Don't design too much up front unless you have a particularly hairy business process. If you are B2C, you have no idea what people will want. you are unlikely to get a statistically significant sample. You are often looking at the alternatives and building for personas. Small work sizes are valuable here. If you are replatforming or rewriting, you should be getting Gap analyses and real requirements because you've had a long time to consider the shortcomings. You may build in a way that gets feedback, but you already know what to build. Don't bother with user stories! If you are with a mature system, the easy problems are likely already solved. You're building larger features that there is no easy MVP because if there was a simple way to unlock the value, you would have already done it. You should be spending more time in unlocking specifications. If you are a B2B with larger business systems, they probably already have smaller ways to do what you are trying to sell them, and they're looking to step up. You likely need better requirements than a user story. However, you likely have access to customers through your customer support teams, so you should be taking advantage of asking them and getting feedback. You probably need something in the middle. Use the tool that meets your use case.