Here we're going to go through an overview of the problem scenario sprint. So this deals with this critical area where we figure out who is our user, what makes them tick, and what do they actually care about? So that the software we deliver is valuable to them in that it solves a job, a desire, a habit that they actually have. Now we're just going to run through this at a very high level as kind of a preview of what's going to come in the subsequent module that's all about the problem scenario sprint. The concepts that are going to be important are, of course, personas. So drafting them, think, see, feel, do. Problem scenarios, these structured ideas about what actual jobs, habits, desires they have at the present moment, and then drafting the interview guide. And of course we're also going to be writing user stories at the end as we will all of this sprints. So that's a critical skill set. And then in Module 2 itself of this course, we're going to talk about the practice of going out and finding subjects and interviewing them. And so on day 0, you're prepped. Probably the single biggest thing is this whole business of thing around getting subjects. So having a good screener, who are these people, how are you going to get them, practicing your interview technique. That's what's really probably the most critical thing on prep for this sprint. The brief, what is the input into the sprint? How do you establish a charter in definition of success that's actionable, valuable and that your team will understand? It'll generally have this basic syntax that you see here, so we want to learn how certain persona or segment does this certain thing in this problem area. And we want to do that because we have some sort of idea of presumably, of something we're going to do with software to make that better. And we're going to deliver these certain things that are going to help us do that. So early on at HVAC in a Hurry when they're still learning about what does it mean to make our technicians more efficient with software, a good charter with kind of adequate abstraction and specificity might be something relatively general like, we want to learn how HVAC technicians prepare for and complete jobs. It's pretty general, but that's okay, because that's where they're starting. And they're doing this because they want to understand the company's learned best practices and exploit opportunities to encapsulate those into software and operationalize them for the technicians. And they're going to deliver personas, problem scenarios, and some preliminary user stories. So they'll make sure that they have a nice clear view of who these people are and what makes them tick and then they're going to drive to some ideas about what that might look like with software. Even if they're going to go forth and do another sprint, they want to constantly make sure that they're thinking about where would we go with this, how would we execute against this understanding we just acquired. Here's another brief where maybe the HVAC in a Hurry team is, later on in the game, because remember, these aren't just things you do at the beginning and then check the box and they're done. They are things that you come back to whenever you have this type of specific question that's pertinent to the sprint type. So maybe now they found that they want to learn it all about how these guys and women technicians go out and get replacement parts to jobs. And how the technicians work with the central office, their support system to go get that done, how does all that work? Because they want to look at whether they could automate the things that work best with software. The general outputs are the same. Enable Quiz is the startup we've been playing with in our examples, and a charter for them might be, well, we want to learn how companies that hire engineers screen or do their preliminary screening around these kind of hard skills of engineering topics, basically. Because we think there might be an opportunity to introduce a quizzing system that'll empower the in charge manager to help more with this process and get better outcomes for everybody, including the candidates. So those are some examples of what the brief might look like. On day 1, as we discussed in course one with personas in problem scenarios, we're going to push ourselves to see what we know and understand what we want to get to with these materials. And we're going to create, we're going to draft personas and problem scenarios from what we know. We're going to create an interview guide, we're going to practice it. And then we're going to arrange the logistics to send everybody out to talk to actual real users the next day, the next few days, in fact. Days 2, 3 and 4, we're going to be out doing user interviews, talking to real customers, making notes, taking note of our insights. And then on day 5, we're going to comeback into the office and we're going to share those things. We're going to do structured sessions to evaluate what we've learned, encapsulate it, make sure that,for instance, those transcripts are highly usable and something that we can look back on 30, 90, 180 days and then drive to some stories. What have we learned? If we had to write software next week, which you very well might, what would be our user stories? What would we go implement based on what we learned? That's how you'll wind up this sprint.
