Scenarios are intended to let you have conversations. With scenarios, you stand a good chance of finding areas of requirements that you weren't even thinking about.
Writing things down makes your brain write them down too, and then you stop questioning. If you're writing down a scenario, it should be because:
- It wasn't obvious, and you want people who come after you to understand it too
- You want to be sure that you really understand the behavior of the system, and talk through an example with someone knowledgeable.
Stop worrying about the columns on the board, and think about how you actually interact with your business stakeholders and analysts.
If there's no gap in conversations, you're part of the same phase, and you don't need to differentiate this on the board.
If there's a gap, does it happen before or after you want to start work? There's no reason why business people can't talk to you before hand about the scenarios they want to play. They're not a phase of work being done; they're just an illustration of the behavior you're looking for (before you code) and a test that the behavior is there (after you code). Scenarios are a great way to question your understanding, and your business expert's translation, of requirements.
If you find for any reason that conversations with your business analyst and tester happen in a different phase to actually coding the work, try and make it closer. Ask them what it should look like and knock the GUI up, then get their feedback. Take on board what they're saying and make that the next thing you do. It'll take longer from your perspective, but the quick feedback means that whatever you produce will be ready for production in a usable form, without the knowledge of how you produced it or how you will fix any bugs degrading over time.
In short, don't worry about writing the scenarios down until you've worked out which ones are valuable by talking to people. Good luck.