I'm not keen on this word. "Grooming". I've been doing it (sort of) long before I've learned about the thingie named Scrum, but until this very day I haven't convinced myself to call it that way. Grokking domain, crunching through problems, knowledge mining, functional decomposition - all these work better for me. But this post is not really about vocabulary, but about how to do get as much as possible out of the activity itself. And why do I believe it's needed? Because pretty much everyone is "grooming" these days, but ... also everyone appears to be doing it very differently, reinventing the wheel themselves.

The goal

The only proper way to start is by clarifying the goal. Why the hell do we groom at all? Contrary to the common belief, the reason should NOT be to quickly provide a sufficiently accurate estimate :P The purpose is to gain knowledge up to a level that makes us able to:

• find out the reasonable way (the solution) of solving the problem - you have started with the problem, not the solution, correct? ;P
• assess the feasibility (of the scenario) & identify key risks (to watch/address)
• "slice the elephant" - split the work into functionally-encapsulated parts - to enable incremental development in short work batches

To accomplish these goals, one has to comprehend the business context first. By understanding the essence of the problem, the nature of the opportunity, what kind of metrics we're trying to impact, etc.

The nine "grooming" commandments

Why don't we set up some ground rules then?

1. Don't jump into the technical discussions too soon. These are usually of secondary (at most) importance. Use your time with business stakeholders to pick their brains - what are the success criteria, who are the typical personas, where's the exact value/monetization, etc.
2. Make notes. All the time. Just one person (agreed up-front). You'll thank me later.
3. Organize & inventorize the questions - they may pop up at any stage of work, including the one when there's no SME around, so you may be forced to ask them asynchronously/remotely. Make sure all the questions are collected & so are their corresponding answers.
4. Split your sessions into knowledge mining & technical design discussion. For numerous reasons, i.a.: because you respect your business stakeholders' time and also you'd like to avoid external pressures while estimating.
5. It's OK if you're not able to provide estimates after just one grooming (on the particular topic). It's not OK if you've made no progress during the grooming & have no plan how to carry it on further fruitfully.
6. It's easy for the "slice the elephant" phase to get skewed into purely technical decomposition ("3 controllers, 5 models, 7 tables, 1 queue & 2 batch jobs") - mainly because we make too many assumptions & see "the final effects" (in our minds) immediately. It's very rigid thinking, though - changes will happen, but your overall estimate makes sense only for the initial scope.
7. We all have our (different) mental models. It happens (more frequently than many think) that we use the same words, but have a different understanding of what's behind them - parties part ways being 100% convinced they've reached a consensus, unaware of the pending disaster. The solution is simple: to draw. Visualize as much as possible, focusing on what's specific to the context. Juggle the perspectives according to the needs: static, dynamic, time-related, behavior, data, domain events - whatever helps most in illustrating the key aspects of the given problem.
8. When pictures are not enough, examples come to the rescue. White-board dry-runs, story-like user "journeys", even "prototype-y" mockups - all options are in-game to bring the scenario currently being drafted closer to reality.
9. Sadly, strong personalities who just want to "get the shit done" are quite good in ruining groomings (despite all their good intentions). How so? They take the lead, set the quick tempo in presenting their way of thinking and don't expect anything else than a nod (because they are confident they are "right"). They forget they have an advantage of knowledge/experience, so they expect that things that are obvious to them should also be evident to everyone else. That's why all present people should contribute, take active part & rotate on such duties like white-board sketching or summarizing. And in the end one should never ask: "OK, is it clear for everyone now?" but "OK, <silent one>, can you recap the solution with your own words, please?"

All the guidelines in the list above are very important, but personally (based on my own experience) I find the following realization even more revealing (I would even say: game-changing).

If your grooming is purely technical & you just "translate" the harvested requirements into tasks corresponding to building blocks (semantic constructs) of your chosen language/framework/library, your solution may be short-term optimal, perfectly crafted (in terms of artisan craft), but it's very brittle & non-future-proof (business-driven changes are likely to make it collapse quickly).

But otherwise, if your grooming is functional & you build a conceptual model ("design") which is technologically agnostic but based on simplified perspective on actual domain problem, implementation should be a piece of cake (because the problem has been split into smaller highly coherent & reasonably coupled functional "sub-problems") and the future changes far more bearable (because domain-based model will be a subject of domain-driven changes).