Defining service boundaries: how small should a microservice be?

we're in the process of splitting up a monolith, and the most contentious debates are always around defining service boundaries. everyone agrees on microservices, but we can't agree on how small a service should be. some advocate for single-entity services (e.g., `user_service`, `product_service`), arguing for maximum independence. others prefer business-capability services (e.g., `commerce_service`, `inventory_service`), where multiple entities might live within a single service if they're tightly coupled by a business process. too small and you get chatty services, distributed transactions nightmares, and high operational overhead. too large, and you just have a 'mini-monolith' that's hard to scale independently. what heuristics or principles have people found most useful for drawing these lines effectively, especially when transitioning from a monolith?