You learn techniques to write great user stories, thread those back to sources of valuable narrative about the user. Now we're going to look at how to bring that material forward to the rest of your team with meetings, or really collaborative experiences, we'll call them. These have three principle goals most of the time. One, is to elevate the teams understanding, allow them to understand what constitutes success and how you're going to verify that. So that they can bring a maximum of creativity and energy to the tasks at hand. It energizes us when we understand what it is that we're doing, and why we're doing it. And so the next item is we want to create empathy with the end user. Probably not everyone on the team is going to have time to go out and talk to the users. Now, a really bad version of this is well, I wrote the user stories, I put them in JIRA or some system or whatever. And they can read them, and they should get it. Well, they won't get it. You need to do a lot to bring this material forward especially if your team is new to this means of driving a value through empathy with users. And we'll talk about ways to do that as we go through here. And the other goal is to plan executions. How does this understanding that we have translate into thoughtful and valuable next steps. The goals will vary a little bit in relative importance depending on where you are in a project. But it's really important to keep an eye on all three as you progress, and not just get into the mode where you're focused on, for example, output instead of making sure you're driving to valuable outcomes. And instrumenting the means to test that into your work. One thing that's really important as you're moving through this material with your teams is your ability to create this progression, kind of slice and dice things into the type of questions that you're having. So that you can figure out, okay do we need to peel off into a design sprint which we'll talk about in course two. Or, are we okay here? We just need to do some preliminary investigation before we start the next sprint. And it's important to work backwards because you should be constantly instrumenting observation into the software that you put out there to users and customers. And making sure you know how you'll observe whether things are valuable or not. And I know that sounds hard, I mean, you're probably thinking it's really hard to just make my release dates, how am I going to do that? And I would say that it's more important to produce valuable software that's focused on things that are important, than to produce a lot of quantity. Now, managing that is tricky. That's what we're going to spend time on in course three. But, I will say that having these kinds of observations and being able to answer these kinds of questions about what you've released will really help your team be thoughtful as they continue to progress and make the software more valuable. Here are examples of questions that are good tools to bring this kind of thing forward. The five whys is a classic line of questioning from the lean methodologies, where we just go through and we really look at the heart of the matter. Why do we think this is important to the user? Why are we putting a button here? You constantly want to be asking, who is this person and what problem are we solving? And we saw some techniques on how to decompose that and structure that understanding in the last slide. And you want to look at, what's our proposition here? How are we going to know if we're doing better than the alternative that the user currently has to do this job, gratify this habit. And then this is a great one. As we've discussed, what is the reward in this story? How would we evaluate and test a successful outcome for the user in this particular interaction? Here's an example of how to design a meeting for a particular situation where you want to do a few things. You want to review personas and problem scenarios, and you're hoping that people will review the current personas. You ideally want to have a link here to your Google doc or wherever you're keeping those things. Then the outcome is we have a strong shared understanding of our primary and secondary users of this product. Now this is where the interesting part comes in. I'm going to show you how to use a game called Day in the Life to create that engagement. Because odds are, if you do a great job of writing a bunch of personas, ask your team to go read them and make sure they remember them all. Well it's probably not going to happen, but Day in the Life is a great way to get engagement, and we'll look at that in the next video. Let's say they want to, they have a bunch of epic stories that they want to go through in detail. Storyboarding is a great interactive tool to take, say we have 20 minutes allocated here. Take 10 minutes, everybody drafts a story board. And then you spend 10 minutes sharing those out and talking about the things that they identify, the gaps, and what those mean for going through and creating child stories. And then, maybe all this work here helps you think about some things that you're missing. Things that you just really don't know about the user at the moment and that's okay. It's important to put those things on the board and prioritize them. So, somebody, maybe the whole team, is going to do a design sprint next month, make some time to go talk to some more users. Well, what do we want to ask them? How can we use the perspective of the team to make that more focal and more valuable? Do you have time to do this? The lack of agendas for meeting, especially in bigger companies, has always astounded me because anybody can call a meeting with like five people. And that's probably going to cost the company quite a lot of money. So, even if you don't have the authority to buy a box of paperclips, you can probably call a meeting that costs hundreds of dollars. And to create a thoughtful agenda like this, making the assumptions we have here, that probably costs you like $13 of Company time. So will it make your meeting 0.03% better? It probably will, and by the standards that the meeting was investable for the company, you should want to go ahead and create these meeting agendas. Now I say it's going to take ten minutes here. It may take you less. Certainly, the first few times you do it, it'll probably take you more time. But I think you'll probably find that the people that come to the meeting will really appreciate it and you'll get a reputation for being a really great collaborator with them. Let's look at one more example before we close. So this is a meeting where they want to review problem scenarios and they're going to punch through and create some material to inform their next sprint. Spend a Dollar is a technique where we look at a bunch of problem scenarios and people vote on them. So you have a dollar and you get to allocate the 100 cents that it composes it into different problem scenarios depending on which one you think is most important. And then the group shares that together, and the rest of these things are basically diverge-converge activity. If you remember, we talked about in module one the double diamond pattern of design where we diverge here and then we go and we converge, so we come up with a bunch of material. And then we compare it together and kind of edit it down to what we think is the best answer. Now, you'll know that this is working if you have stories that have all three clauses. That's a pretty basic thing, that usability and motivation on the part of users are both tightly linked to stories, but they're tested separately. And if testing feels easy and frequent and really integral to the things that you do, that's another good sign. Agile is inherently very test driven and as you continue to practice it, you'll develop more of a test driven mind set and a culture of experimentation. You want every story linked to problem scenarios and propositions. So you're constantly able to look at and answer for yourself, why do we think this is going to be valuable? Even if you haven't had all the time to test those things that you would like, at least they've been made explicit. They've been spoken aloud, they've been put in a Google Doc or up on a board. And if you run into trouble, you'll have some really specific ideas about what to do next. And then finally, every story is linked to a nice, vivid persona so you know who your user is. Here you've learned how to conduct valuable meetings, so that you use your team's time efficiently and effectively and you drive that narrative collaboration that we're learning is so central to Agile. And in the next video, I'll show you how to conduct a few of these specific techniques, like Day in the Life, to make those meetings better, and to really bring that material forward to the rest of your collaborators.
