Designing a Meeting with User Stories

You learn techniques to write great user stories and thread those back to sources of valuable narrative about the user. Now were going to look at how to bring that material forward to the rest of your team with meetings orderly collaborative experiences we’ll call them. These have three principal goals most of the time. One is to elevate the team’s 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 value through empathy with users. 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 get into the mood 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 implementing 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 just to 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. But I will say that having these kind of observations and being able to answer these 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 some questions that are good tools that to bring this kind of thing forward.

The five whys is a classic line of questioning from the lean methodology, 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. 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 succesful outcome for the user in the particular interaction. So 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. And then the outcome is we have a strong, shared understanding of our primary and secondary users of this product. Now, this is where there 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, as 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 have a bunch of epic stories 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 storyboard, and then you spend 10 minutes showing 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 all the things you’re missing, things you don’t know about at the moment and that’s okay.

It’s important to put those things on the board and prioritize them. So somebody and maybe the whole team is going to do a sprint next month. Go on and make some time to go and talk to some more users. Well, what do we want to ask him? 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 meetings, 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 paper clips, you can probably call a meeting that costs hundred of dollars. And to create a thoughtful agenda like this, I mean making the assumptions we have here that probably costs you $13 of company time. So will it make your meeting time 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 10 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 get a reputation for being a really great collaborator with them. Let’s take a look at one example before we close. So this is a meeting where they want to view 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 is 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 proposition. 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 into 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 affectively. And you drive that narrative collaboration that we’re learning is so essential 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.