I answered your general point in a separate reply, since others brought up the idea of continuously planning and retrospecting in kanban. But I'm confused by t

I answered your general point in a separate reply, since others brought up the idea of continuously planning and retrospecting in kanban. But I'm confused by this statement: >planning is just complete BS To me, planning is where design meets reality. Planning involves several activities, but probably the most important is prioritization. I'm curious why you think that prioritization happens more frequently in kanban, where the convention is to simply take the next task off the stack. Are you saying that every time someone takes a task off the kanban backlog, they independently re-prioritize the entire stack? Or do you have regular re-prioritization sessions with the team? If it's the former, that seems like a lot of overhead and opportunity for conflict and misunderstanding. If it's the latter, how is that really different from regular sprint planning? Because surely, as part of the prioritization, you would also consider things like estimation of difficulty and risk.