 Whoever is going to work on it and whoever provides input to this story, whoever is involved in this story in any kind of way, put them in a room, spend 15 minutes talking through the story and come up with some examples to describe this story. And when you do that, some amazing things will happen. Well, first, you create those examples that will come out of it, but the next thing you'll discover is with these examples, you'll start to notice that the business rules around this story become clearer, or maybe some of them are already defined, but you will discover new ones. You will realize that the ones that you already knew about were ambiguous or unclear or contradictory. But as soon as you start talking about concrete examples, people can visualize it. You can see where it's inconsistent. The other thing that you come out of these meetings is questions. Every now and then, the developer will ask the product owner about something, and the product owner goes, that's a really good question. I don't know. Let me try and find out. And then you can just park it. What you've just done is to promote an unknown unknown to a known unknown, that the BA or the product owner or the domain expert or whoever it is, can go back and analyze and find out about before you start writing the defective code. So I said 15 minutes, because it's important to keep these meetings really fast and really frequent. You want to have a 15-minute meeting for every story like this. So don't try to solve the problem or get an answer to the question. Just write it down. Another thing that happens is that you can create smaller stories. Tomorrow in my workshop, I'm going to do this, so I'll show you some techniques about how you can come up with more examples for a story. But one thing that happens is for some stories, you'll get a lot of examples. Or for some stories, you'll realize that there are so many different rules. When you see that there's lots of examples and lots of rules, well, that's an indication that this is a big story. You can break it up into smaller chunks. And it's much easier for the product owner to realize the magnitude of what they're asking for when they can actually experience firsthand through a conversation that there are so many different paths here, so many different examples. We have to break this up. So stop breaking your stuff up by tasks, user interface, domain, layer, persistence. Break them up in examples which are more like horizontal, sorry, vertical slices, which is just like this is one path through this story, this is another one. But perhaps the most important thing that you get out of this meeting is not even any of these. It's that you get a shared understanding between everyone on the team. And some people have told me that this actually has some amazing effects. It helps people create empathy, it helps people be more empathetic. When things go wrong, which they always do, even if you do three meagres meetings, it's harder to blame one another because everybody was in the same room and gave their best shot. So if you have a problem with blame in your organization, this is a great tool to just get rid of that toxic culture. There's absolutely no excuse not to do this. Just try it out. Don't say it's BDD, just try and grab some people and say, can we have a quick chat, talk through some examples, just see what happens? You'll be amazed. So, yeah, because everybody has a different perspective. So talking about perspectives, what I see a lot of people do when they're trying to adopt BDD is we have this syntax called given.