Grooming, the famous story points generator, the place you go to with a humongous list of stories and return with accurate story points for each of them. That sentence is wrong on so many levels that it could hardly get worse. Now it's time for tactics. Grooming is your primary weapon of choice. Lock and load.
From the previous brain flush (Agile, Scrum, and Some Other Swear Words), you should already be aware of misused processes. You've chosen Scrum because you have your goal, your motivation to do so.
There's one excellent reason to hold a grooming meeting: to discuss the work in front of you, to gather your thoughts about the risks, tasks, known issues, and overall benefits. And yes, you can find out that some stories just don't make sense or are missing entirely. The solution to a big problem consists of many steps that change a lot as you move further with the solution. The steps to solving a problem are never carved in stone.
Grooming should be a magical place where you go with problems and return with a lot of ideas that will resolve the problems. Those ideas are represented as stories. And story points? They are the crucial tools for spreading knowledge and creating stories with enough clarity. Yes, there are also other useful benefits of story points, but those two are the most interesting ones.
Spread the Knowledge
When you're playing so-called Scrum poker, your goal is to get one particular number. Everybody has to be confident with this figure and if not, they have to argue. The vast majority of the risks and struggles will be heard during this process. And that's the point, because everybody in the room will hear it and learn what the heck is going on. QAs could raise questions about testing scenarios. Developers could talk about rare use cases and the impact on other existing features. Technical writers may have a few words from a documentation standpoint. There's no better way to learn the complexity of things than this kind of discussion over a real issue. And believe me, the actual benefit for the product owner isn't the number, but the assurance that everybody knows what's going on and why. Or, at least, I hope that's the case when the question shoot out is over. So please, for the love of God, ask when you feel lost. I'm positive we would rather spend a little more time discussing things during grooming than firefighting some shitstorm during the Sprint.
Clear Enough
Knowledge sharing is in progress, but the discussion is still going nowhere. A ton of questions were answered, and another ton is waiting. The Scrum poker result is either a big-ass number, or everybody has a different opinion about what it should be. That implies one thing, the story is way too big to comprehend. Let's slice the repulsive rascal into pieces. How small? That's up to us. I can advise you to make it as small as possible. Keep splitting while the stories still make sense. The benefit is fairly obvious. A small atomic story should be clear enough to make a quick estimation and see all the risks. Also, you can quickly prioritize these smaller stories. Who said you have to implement every slice? The process of splitting might reveal pieces that aren't necessary, and they can be skipped if time is an issue. Could you do that with a 21-story-point bulldozer? During the Sprint? I don't think so.
Tips and Tricks
There was a time when I used to sit in the corner during every grooming session in our company—making notes—silently judging. The purpose of this act of valor was quite noble. I was observing the good and, especially, the bad things we did during the grooming meeting. Long story short, I've learned a lot, and it's right to share some of my findings with you.
The estimation is the hard part of grooming. I find it very useful to show some of the previously estimated stories before a new round of estimation. I think it's an excellent reminder that everybody should compare the stories and not try to find out how much time they're going to take. It was also very handy to invite somebody with domain knowledge for the stories outside the scope of the team. There are always a lot of questions regarding the unknown, and an outsider can help keep the meeting going forward.
Let's move to something not particularly great. If you want to deliver an excellent solution, there has to be a very good motivation. This motivation was missing in the vast majority of our stories, which was a big issue for us. The solution is in the minds of the people attending the meeting. If you don't know the motive, ask about it, and when you are confident about it, always note it in the story. It's one of the most valuable pieces of information. We dealt with it using this simple rule. Worked like a charm.
Another thing in which we sucked big time was the acceptance criteria. Now, we always remember that the acceptance criteria are not technical steps for what to do and where. The story is never a bullet point list or a step-by-step tutorial. It's always only a definition of the use case we want to solve, and the acceptance criteria are the points that have to be accomplished to somehow resolve the issue. But the "how" is up to the team. You can write your technical guidelines into the story, not as acceptance criteria, but as notes because they could (and probably will) change during the implementation. And even if there are some technical notes, we don't follow them blindly. We do not implement something because it was written in the story. The assigned developer, technical writer, or tester must have a little think about it and solve the issue accordingly.
Believe it or not, the estimation phase is very demanding for the presenter. It's very easy to get diverted from the topic and hard to keep it on track. That's the very reason why there should be a facilitator that will help the presenter to keep the discussion going the right way. I attended grooming sessions where everything was on the shoulders of a product owner. However, I saw other ones where the estimation phase was facilitated by the ScrumMaster. The difference is huge. The product owner needs some time to summarize the information about the previous story and prepare for the next one. But this is only possible if somebody takes care about the estimation. If not, that poor guy is still in a hurry processing millions of things and eventually will be super ineffective. Keep that in mind.
There were a few more issues that we had to overcome, and we did. We have very experienced development teams in the company, and the grooming sessions are no longer a tragedy. Motivated people with a clear vision can deliver epic products. Our last major flagship product release was proof of that. There wasn't a lot of people that believed we could pull off a billion activities under a heavy load. But we did because we know how to groom problems, even ones this big.
Do you see the reasons why we meet in crowded rooms and pull out Fibonacci numbers? Nobody wants meaningless numbers generated in a hurry. The goal is to prepare ourselves for the upcoming challenges, and when we are ready, and nobody suffers from Jon Snow Syndrome, we can be sure the estimates will help us with planning and not just lead us into the flames of hell.
But what about you? How do you groom your stories? In a one-hour-long useful meeting or a dreadful never-ending one where time stands still?