I wanted to dive in a little bit more specifically on the user story and how to create good user stories so that: A, if you decide to refactor some of the design inputs for your own work, you have this as background about doing that. Two, as you consume user stories and use them as a coder, that you have some background about what to expect and how to apply a good user story. Probably the biggest thing I see when I'm working with students and advisees is that their user stories are too big, too broad, and too big. So the idea is that we have an epic and just finding a part and getting its pricing and availability, is a good sized epic, I would say. But that's a relatively small thing. So usually when I see students write their first few users stories, they read a bunch of, they write an epic that's the story of their whole entire product, and then a bunch of child stories that are actually themselves epics. No big deal and that's fine and everybody seems to do that in industry, in degree programs, online. But that's the process that I usually go through, is making user stories smaller, is usually what needs to happen. So consider that. Then as we go into these child stories, these are really small. What's so good about having small user-stories? Well, I would say in practice, it's every time we're investing in code, we're spending a lot of money to both create that code and maintain it, and it is a worthwhile investment to make sure that as people are coding, they have a relatively specific view of what they're trying to achieve. So again, we're not trying to prescribe how they execute exactly, although we may want to collaborate on that through designs and iterating, but we want to have a pretty specific idea of what constitutes success for whatever you're coding. If that's really broad and really vague, we're losing the opportunity to help ourselves focus our coding and make sure we know what we're doing. That's the importance of having them be small. So epic sounds big but really it's not that big, they're small, they're specific. Here's some examples of a few other epics, and there's some resources in the course. If you want to have a look at this, let's take a look at this one, and let's look at how this unpacks into a storyboard. So I take epics and I usually storyboard them. I think if you want to do a new epic or re-factor an epic, a storyboard might be a good way to complement that. I like to think about trigger, action, and reward. So how does this story initiate what do they do, and how do we know if they're successful or not? So here's how that breaks down for the storyboard you're about to see. Now, you're familiar with this. So I won't bore you by reading through it. We know Ted finds that he needs to replace a part. We know from our field research with these texts that sometimes they know the part number, and that's how they're going to look it up. Sometimes, they have to go through the vendor. They have to filter it by vendor and type of part because there isn't a part number on it. Sometimes they just get stuck, and they don't know, and they have to take a photo and ask for help from dispatch or the central office. Now, he wants to be able to find the pricing and availability and talk to a customer, and if he can do that for this epic, we got success. So now with that, we unpack this. Remember, the user story as you unpack from epic to child stories, is not always a happy path. A lot of the time it's more of a web, like for example, in our story we've got a web where there's three different types of ways that he might search for it, and then that converges on determining delivery and discussing with the customer. So we look at how we might take our ideas of trying to put ourselves in Ted's shoes in the storyboard, and relate that to a bunch of child stories that help us really focus and think about how that unpacks. Here's what that might look like. These child stories that you're probably a little bit familiar with already. All right. So that's a little bit about how we structure user stories for a maximum of actionability, testability, and above all, focus as we go from idea to code.
