How do you design meetings around these user stories where in a conference room or maybe even just sitting at our own desk, we feel like we have a lot of control? "I'll this user story, everyone will understand it the way I did. Somebody will develop it, the customer will love it." Of course, things never go that smoothly in practice. It's really important to involve your team in these user stories particularly since that's the whole point of user stories. They are not a blueprint, a specification, they are a placeholder to have a discussion, there's one thing you might hear. I'd think them as a provocation to consider what the implementation really should be. Again, the amount of quality questions you get back, the quality discussions you have, those are going to be your signal about how effective you're being with these user stories. Let's take a look at a few ideas for organizing meetings or sessions with your team around these user stories where you can get them more involved. Your goals with these meetings are to, one, elevate the teams understanding. What's a successful outcome? How does that translate into the next steps? Not just telling them, but also hearing how they think it should be done. You're co-creating that point of view with them. Establish empathy for the end user. How does everybody know? Not everybody's probably participated in the design research. One good trick that we'll look at here shortly is using gain in your life to get everybody involved thinking, talking about the persona. Then we want to tie this to the execution. We want to ask people what they think their next steps are based on this. Do they understand? Can they envision themselves taking those next steps to the end? We want to be able to recap with them or ask them questions, see what they say to us about this chain of things. We want to make sure we know who we're building this for, what's on their A list, how we validated demand, or at least what assumptions we have to prove to be true to have a valid demand hypothesis, a basis for demand or product market fit if you will. Then how are we going to make something entirely usable? These questions should be on the board. The linkages between these things ideally exist. It takes work though. Without this though, you're going to move from design to code. Then the hallmark of these things is that when the product is done and you're seeing it, you're surprised. Probably the easiest way to tell whether this is working or not is, are there surprises at the end of the iteration or sprint when you go see the working software? They really shouldn't be if this is working well and if it's not, some ideas on questions to ask during your retrospectives. Great questions that are tend to be useful in these meetings is this five whys. This is easy to understand. We just keep asking, why didn't get the root of the problem? A lot of the skill and actually doing this is creating an environment where people are inclined to participate in a sincere way and really think about that rather than react to the question defensively, because we all make mistakes, we all do things wrong. We have to look at ourselves like athletes or something where we're just trying to learn how to play the game better. Who are we talking about here when we talk about doing a feature, what job are we doing? What's our proposition for building this feature? Why would it will be valuable to them? What would we need to test? What we need to be true for that to actually be valuable for them? Then above all, what's the reward for this user story? What's our definition of done in terms of analytics? How might we test this with individual subjects? Here's an example of a meeting agenda to warm everybody up and get them involved in this stuff without them having to do a lot of advanced preparation. You can do the day in the life gain, which we'll talk about shortly. Story-boarding is a great thing to do with the team. You could do a diverge, everybody does on their own storyboard and then you collect these and look at them. You can dot vote on them, for instance, which is a practice where you give everybody about 25 percent as many sticker dots as items there are. If you have a team of eight and everybody makes a storyboard, then they would get around two sticker dots to distribute, you would talk about the storyboards that everybody found most compelling for example. Then you might prioritize some customer discovery questions. How would we ask somebody this? What are the questions? You may think, "Well, I'm too busy to prepare for these meetings." It happens a lot. There's this gorge of being busy, which really means we have to prioritize more aggressively what we're doing and not doing. Admittedly, it's easier said than done. However, just to give you a little bit of creative confidence that this is really worth it, here's some simple arithmetic about, at least in US salary ranges for this type of work. How much is such a meeting cost and how much does it cost you to take 10 minutes to look at the agenda and prep and create more of a high-quality experience with your team? Here's a second meeting design. We're more focused on story writing. We might review the jobs to be done, dot vote on them, diverge, converge the epics. It's great to go ahead and have everybody write a version of the epic for a job to be done that they've identified and converge those, edit them together. That's essentially what you're doing here, essentially the same process we looked at. You would diverge, converge some epics, diverge, converge some storyboards, and then do the same with child stories. Those are some ideas on getting your team involved in this material, in these findings that you have about the user. A few good signs that it's working are that your story is consistently have all those three clauses, even if you're not the one writing them. Usability and motivation are tested separately, but they're always considered and linked back to the user stories. Testing is something that everybody thinks about in a very integral way. Not with, "By the way, how would we test that?" But just as we texture things out, we think about testability. Everything's linked together, and we have a strong basis for understanding how our user stories would hypothetically be valuable. When we don't have those answers, we admit it and we do one or two things. We either admit that we don't have enough, but for some reason we have to move on and do this, or we go and make a little bit of time to do just enough research. Those are some ideas about how to make your team more involved in understanding where the customer is coming from, what their problems are, how you validated the propositions or what the propositions are, and how that relates to their work on the product itself.
