You've learned about when you may want to do these experiments, how to attach them to your regular work articles and cadences. And now we're going to look at how to execute these experiment ideas through a series of specific experiment types. So let's start with the feature type, this is a good composite. Because as you mentioned, this has to do with both motivation and usability or ability. The narrative we'll use for example purposes here is this one we've been playing with for HVAC in a hurry. If you remember we have Ted the technician finding that he needs to replace a part to complete his repair. He may know the part number, and want to search that way. Or he may say, I don't know what this thing is, but I think I can figure it out. Or he may be totally stuck, and want to take a photo, and then ask for help. And those are things that the team has observed the HVAC technicians actually doing. And so, they took that narrative, and they went through, and they planned the execution of these in their back log. And if you'll remember, they did the first search feature, then they executed these narratives here, so they would be able to have a complete narrative arc. Let's say, when they got to this narrative here, about taking the picture, they ran out of time. And they said this is a whole lot more complicated than we thought. And maybe you are asking, I thought I saw the skit where they thought it was all going to be fine. And they were going to, was going to go through and do all the stories in the sprint. Well that's life and that happens in Agile especially, that was their first sprint especially when you're first getting rolling. Your ability to predict how much you can get done and your ability to scope those stories out well. And tease out the details so that the implementation is well understood initially is going to be highly imperfect in the beginning. And that's okay, it's fine, and it's not that Agile frees us from accountability, it doesn't. It just frees us from the practice of blaming, there doesn't need to be a blame holiday on the Agile calendar. Because we have these regularly scheduled retrospectives where we look at how did we do, and let's think about how to do things better. So, the HVAC in a hurry team, for example, would look at that epic or, I'm sorry, it's just a story, this is the epic here. They would look at this story and they would say, well, we really didn't do a great job of thinking through the details of this before we started. What can we learn from that, and how can we do better backlog grooming or sprint planning meetings where we teased out that detail so we really can think about what we're going to get done. And maybe make sure that we get tree all the inputs and narratives, sample data, stuff like that, before we start. But back to the question at hand, what do they do now? Maybe now they look at this and they say well this is a lot more work than we thought and we observed technicians out in the field doing this. We have some evidence that this is going to be valuable but can we maybe re-factor this idea some because it's bigger than we thought. To do an initial test of it to make sure it's really investable for all the work we would need to do? Because let's say they found that the plumbing to get this photo out to the dispatch people and have it routed to the right person. Get a timely response, make that available to the technician, that that was a lot of plumbing, both on the coding and the process, so, they re-factored the idea. From a coding standpoint, they figured out that, well, it's pretty simple to allow the technician to upload a photo to the web and send that in an email to an email list. And, while it's not scalable for them over time a group of people in dispatch agreed that they would respond to these and just respond by email to the technicians. So they've re-factored the implementation of this narrative to be something where the technician uploads a photo. They submit, they get a repose that says hey look for and email with this title. And we're going to respond to you on what this part is, how much it cost, when it's available asap. And then they look at their email and they get a response that way. So it's not as tightly instrumented and set up as they originally thought it might be. But it should be pretty workable to see whether the feature is fundamentally valuable before they invest a lot of time in building it out. So that's the setup for our test execution of this thing, this feature test. In the next video we'll look at how the HVAC in a hurry team is actually going to put this test together to make sure that they can run it effectively, and drive to a definitive result about whether this feature is something they should just scrap. And look for alternatives or invest in more and skill up and make it tighter and better implement it.