The Last Responsible Moment
If you have to write it down, you're collecting the information too early.
The concept is "last responsible moment." Collect the information you need to build something at the last responsible moment.
When people try to justify backlogs, they usually say, "I need somewhere to remember stuff." Those folks are describing waterfall up-front requirements gathering, where you collect information for weeks (or months) leading up to implementation, then implement based on that info. The problem is that the information is invariably stale and incorrect by the time you get around to building. Every release changes the domain, and those domain changes are not reflected in your stored requirements.
Probably the best example of that failure that I know was IBM's repeated attempts to update the US air-traffic-control software. They spent a year gathering requirements and creating a design. At the end of the year, both the hardware and procedural systems had changed. So they threw away the year's work and started over. If my memory serves, they did this four times and never built anything. They had a great backlog, however.
So, I believe that software construction is about learning. We learn what to do next by building the current thing. I use nothing but one-sentence (if that) story cards for planning. No details on them. Just before I start building (hours, or maybe days, but no longer), I collect enough details to start the work. (And yes, I do take notes, so I guess Iām writing something down, but not much š.) I build something, release it, and get feedback. As I do that, I have conversations in which I collect details on what to do next. It's a "Hey, come over here and tell me what you think of this" sort of process. I do have strategic goals that guide the process and give it direction, but not tactical ones.