I have found a simple rule useful: if you know what the end product will look like and how it should behave, you're not "doing Agile", and there's no point in p

I have found a simple rule useful: if you know what the end product will look like and how it should behave, you're not "doing Agile", and there's no point in pretending that you are. If your PM or client can look at a piece of software and say "this doesn't behave like we expect it to" or starts asking "when can you have that done?" (and they're referring to any unit of time smaller than a quarter-decade), batten down the hatches and start writing requirements. The last job I worked at still had defined features, test cases, and release dates for its projects, but since they were "Agile" they stored all of their "user stories" (read: free-form requirements that needed to be built according to a literal separate design document) in Jira tickets. I worked there until the urge to play in traffic became too strong.