I am editing my answer based on the feedback I received to further help understand how and when should you be work on the Requirements and Sprint Planning stage of your Sprint; as also on applying the Kanban Method to your current processes. For the purposes of my response, I am using the terms "Kanban" and "Kanban Method" interchangeably, by both of which I mean the recommendations of the Kanban Method. I hope this helps.
Firstly, you should not change anything about your Requirements development/ elaboration process "for Kanban" - because Kanban does not make any recommendations there. All Kanban recommends is that you visualize your current processes, including around Requirements management and Sprint Planning, implement WIP Limits and manage Flow. Thereafter, make any changes to your process based on bottlenecks and opportunities for improvement observed.
[I strongly suggest, that if you haven't yet, please read the book - "Kanban: Successful Evolutionary Change for Your Technology Business" by David Anderson, the Kanban Method pioneer. (Full disclaimer - I am a co-founder at a Kanban product company. I am also a Lean Kanban University certified Kanban Coach and Trainer.)
Kanban in itself is not a software development/ project management methodology. Without an existing process, you cannot apply/ implement Kanban. It is a method to help you improve in an evolutionary (gradual, non-disruptive) manner whatever your current processes are. In your case, that is Scrum. So, you should really be applying Kanban on your Scrum processes to help your team improve its software delivery. The combination of this is popularly known as Scrumban.
You would start by following the 3 basic principles of Kanban -
- Start with what you do now
- Agree to pursue evolutionary, incremental changes
- Respect current processes, roles, titles and responsibilities
Using these as your guiding principles, you then implement the standard practices of the Kanban Method - which are -
- Visualize your current process (and the ongoing work)
- Limit WIP (Work-in-Progress)
- Manage Flow
- Make process policies explicit
Start with these 4 practices. There are 2 other practices defined in the Kanban Method that you can look at once you get started and have a handle on. These are (5) Implement Feedback Loops, and (6) Improve & Evolve Collaboratively, using the Scientific Method.
This is a quick summary - the book will really help you get a better understanding of these. There is also a comprehensive Kanban Guide available on our website.]
The important thing to focus on in your situation is to visualize (on a Kanban board) what you are doing today. Your current Requirements process should be followed during the Sprint Planning process or some sub-steps you might choose to visualize. Your Kanban board should, in fact, reflect the Sprint planning as a specific stage of the overall dev process, followed by technical design, dev and test, as the case may be.
While user stories are in the sprint planning stage, you would follow the steps within that such as the BA providing you details, developers preparing questions and getting them answered before the story moves to the tech design stage and beyond.
(BTW, if your Requirements process has any upstream aspects which might be considered to be part of roadmap planning or backlog grooming, there is a whole topic of "Upstream Kanban" that helps you better manage upstream activities in as much detail as they might exist today. You or your BA/ PO could consider using a separate upstream Kanban board to manage all that activity.)
Your Dev Kanban board flow might look like the one below -
Backlog --> Sprint Planning --> Tech Design --> Dev --> Test --> Integrate --> Done
Each of the stages might have their own "In-Progress" and "Done" sub-columns - although if a single developer takes it thru all the stages, you might not need those sub-columns at each stage. If you feel it is important, you could break Sprint Planning down into 3 sub-stages - Story Detailing, Clarifications, and Done, so potentially you could study bottlenecks in each aspect of the work. For example, in our own dev team, code review can be a bottleneck often!
At the end of your 2 or 3-week sprint cycle, all user stories that are completed can go out collectively - and you start with the next set of stories from the Backlog.
Over a period of time, you might decide that some of the challenges of doing Scrum (story leakage, missed sprint deadlines, etc.) might be dealt with by doing away with some of the constraints/ rules of Scrum - which might appear to be sacrilegious to some. We ourselves do 4-6 week Releases - and don't do Sprints.
But equally well, you could just continue to work with Sprints and Releases.
In our expperiece, this is where Kanban helps you decide what is right for your business or team and adopt or modify your processes that help you deliver your work in the best possible manner, which maximizes flow, throughput/ velocity and reduces delivery lead times (time to market).
Whether you decide to do away with Sprints and just make Releases as and when a sufficient number of features have been built (or defects fixed or a combination of both) - or whether you keep Sprints - Kanban should help your team work more smoothly, eliminate bottlenecks and improve cycle time performance. If that helps you make more frequent releases which in turn helps you get faster customer feedback, now you are moving to what you might term a "more agile" state of affairs, but which might not necessarily fit the classic definition of the Scrum method.
However, if business goals are being met better, customers are happier and your team is able to function optimally, then you would have achieved your objectives of implementing Kanban.
Hope this helps. If you have any questions, I'd be happy to answer them.