Domain-Driven Design in microservices: where do you draw bounded context boundaries?

We're in the process of decomposing a large monolith using Domain-Driven Design principles, and we're struggling with where to draw the boundaries for our bounded contexts. For instance, is 'User' a separate bounded context from 'Identity' and 'Authorization'? Or should they be combined? Similarly, 'Order' vs 'Payment' often causes debate. It feels subjective sometimes, and different team members have strong opinions based on their past experiences. What heuristics or discussions have you found most helpful for defining clear, cohesive bounded context boundaries? How do you resolve disagreements when multiple valid interpretations exist? I'm trying to avoid creating contexts that are either too large and still monolithic, or too small and fragmented.