Lessons

Lesson Info

User Stories & Epics

Now one of the things that we're gonna use, and this may be something that you guys have heard before. Who here has heard of the term, User Stories and Epics. Does that mean anything? Yep, cool (clears throat). So this is something that we're gonna have to get comfortable with. You know, the idea of user stories and epics. So what are they? Essentially what they are is they're gonna be the way that we can kind of, formulize and get a little granular about the features and functionality that we want to include, but we're gonna kind of write them from the perspective of our users. Now what's great is, because we now know who we're designing for, we know the users that we would now apply to this. So if we were thinking about, you know, the ministry of space stuff that we're looking at in the previous session, now we know that there'd be user stories written from the perspective of say, let's see, who did we decide was at the top? We had teachers, Families? Families, Right, we had fami...

lies, teachers, students, and maybe there'd even be some for aliens, it's hard to tell. So if we were to look at the formula here, the idea is that it's always written in this type of way. It almost looks like HTML. It does look like HTML. It's kind of clever. We're just trying to seed that in. It just feels familiar, right? (chuckles) So, as a type of user, I want some goal so that I can have some reason, right? And the idea of putting the reason is you're trying to show little bit of that business value as to why you're trying to do that. So here's a couple quick examples. So thinking about one of our, you know, primary user groups, I was hoping that you guys would hit on teachers, so I'm glad we got that in there, so as a teacher, I want a list of current exhibitions that I can plan a field trip. As a teacher, I want to purchase group tickets so that I can get a educator's discounted rate for my class, right? Kind of diving in, or starting to capture these stories. Now some of the granular features that we're arriving at, depending on who's in the room, you know, often times we'll have our scrub master or technical project manager just start capturing user stories as she starts to hear them. So the user story process, the writing process, the writing process, can happen immediately and you just start capturing all that stuff. So that way you kind of have it, right? We may determine that it's not that valuable, but it can kind of just really start to quickly create a foundation on what's important. Now sometimes, some of these things are a little too big. You know, there's just to try to kind of, make a user story something that's achievable is unrealistic. And so, if you have something that's too big, then essentially that's going to be an epic, right? So an epic is basically a large user story that will have multiple user stories underneath it. So you can see here, as this example, as a teacher, I want to purchase group tickets so that I can get an educator's discount rate for my class, could start to be broken out to be multiple stories. That could be as a teacher I want to be presented with options for group ticket sales. And as a teacher, I want to be able to add in my discount code from group tickets so I can get a lower price. And there would be many others that would probably get woven into that. But you can kind of see now, there's a structure. There's kind of, again, we're kind of thinking in this modular way, in this same way we're thinking of the actual components, there's kind of this natural overlap to how we start think of the user stories and epics themselves. Now what happens, is that if we have an epic, this is often called the Sprint Goal, right? So this, remember those like, cycles, that we have? So what you're gonna have is you can define what that sprint goal is, and depending on the team, the size, and how many user stories there are will ultimately determine what are the goals of that sprint. But this is an example, where it's like you know what? For this sprint, we want to make sure that we can get through this epic and make it functional, right? Like it's going to work. By the time we're done with that sprint, it'll work. It'll be tested, and it will work. So, what we have is we take those user stores, we take those epics, and we kind of put them into what are called Dev Tickets. So the primary thing of a dev ticket, is of course the user story, but there's gonna be other things that you're gonna want to include. So here's an example. So just so you guys know, the tool that we use often is called Unfuddle, so this is a screen grab from an Unfuddle ticket that we created for this project. And, I don't talk through it a little bit. There's kind of a couple key things here. We want to make sure that it first as the story or epic itself. Then, it's going to kind of talk about the milestones. So for us, the milestone will likely be things like, what's the sprint? You know, you have all these different sprints, they're all gonna be kind of like, sequential, so for this sprint one, this is gonna be considered part of that milestone. You might wanna then have what's the component that it's used for. Again, thinking in components, you know, what is this part of? And then also, it's version. Sometimes you might have different versions for, you know, is this for like a new version of the site, or is this old? So you can kind of control the version as well. You know, within that, that's kind of giving you a bit of context, where it fits into how it relates to everything else. And then we have a little bit more information about giving context to the actual story itself. Just having the story, is not likely gonna be enough, right? You're gonna wanna have extra information, you know? This is an epic for ticket purchasing flow. And so, again, imagine a developer is coming into this, and he's gonna wanna make sure he understands everything about this, he should completely be able to understand it. In fact, anyone that's a part of the team, should be able to look at a ticket and understand why it's there and how it fits in. And then the other thing we're gonna try to do, sometimes you might have attached files, you know, maybe there's an image or something that you need. Best practice, I would say, is never try to include really heavy files because they're gonna eat up the space. So use a Drop Box link or something like that. But what you can do, is if you have a screen grab, you wanted to show, or something like that, that would definitely be something that you can include, but don't try to attach say all the PSD's. That's gonna be a nightmare. Don't try to attach really heavy files. And then what you can do underneath, is you can kind of show what are the associated tickets with this? So, these are all kind of the child tickets that are associated to this parent epic user stories. What is a good ticket? It's like it's hard to know exactly what that right level, sometimes you feel like you can be writing too much, or too little, what's that right balance? Part of that's gonna depend a little bit on your team, and the level of communication you have with them, but ultimately best practice, make sure that they're understood by anyone on the team, Make sure they're granular enough to be actionable by a designer or developer. They should have one clear action, don't try to throw too much into what that ticket's trying to do, that's multiple tickets. That's a very easy to try to do, is be like we're gonna pack this one full of stuff. But then it's gonna be really hard to understand and consider it done. That's always a big question, when team members are like yes, it's done! And it's always good to define with your team what done means, right? And then you're gonna kind of what to make sure it's providing links to assets or prototypes or anything like that. And if it's a bug, provide that screen grab and specs on the device and the browser so that bug can be recreated. And in that dev tickets thing, we kind of have an example of a good bug and a bad bug so you can kind of see what that proper format would look like. Now all these things will go into what's called a Product Backlog, right? So you're gonna have this backlog that's gonna have all of these different user stories in them, and epics. So this again will kind of continue to capture the requirements in one place. One place for the entire team can kind of look at it and see where things, what the status of them are. It's also gonna kinda be all the desired work on the project, it's gonna be written in user stories, but you know, this is where you're kind of just talking through with your client and continuing to understand are there new things that are coming up, are there things that aren't relevant anymore? And, at the start of each spring, so every time we kind of have that cycle, you're gonna reprioritize. So, it's gonna end up being in this list, but that doesn't necessarily mean that it has to stay that way. So at first, you might assign all the tickets to the milestone might just be called Product Backlog, and then what you're gonna do is when you're ready to begin that next sprint, you're gonna then reassign them to sprint two, or sprint three, as you start to figure out what you're gonna work on next. So, there's kind of some very high level types of tickets that are worth going over. So there's user stories, which are the ones we kind of just talked about. There's bugs, which are essentially things that are either functionally wrong or visually wrong. And then there's also kind of developer or designer tasks. So, a designer task that you might want to put in there, is I need to research the end user license agreement for the font that we want to use that are selected, or that the client has but they're more print based fonts so I have to kind of see what's available as a web option, and what is the cost of that. Because obviously, as designers, we need to be very aware of the end user license agreement, and we want to make sure that we're kind of working through the cost of some of those options. A developer might be trying to set up an environment. Making sure everything is ready to go. Or I don't know what's a good developer-- Oh a developer task? Task. Give me an example here. The boundary between developer tasks and bugs is interesting. Developer tasks are usually the first time they're attempting to bring a piece of functionality online, like Wire Up the commenting widget, or include the Twitter third party element into the website. Whereas bugs is, well, through review the commenting plugin isn't working, or after review the Twitter widget isn't working, so that would be an example of it. Again, they're both developer tasks, but one is a feature request, start, and the other one has to do with QA and user experience around that task, failing. And sometimes our tasks will also just be in that learning process. You know, just we need to learn and do a little bit of experimentation to understand what are some of the commenting options we have, as far as doing a little exploration. My favorite part of the product backlog is how it maintains the input from your client throughout the lifecycle of a sprint, or the lifecycle of a whole project. I think early on, you might be prone to say okay, we got your feature requests, that part's done. We have all the tickets we can work on. Keep those to yourself. You wouldn't be that rude, but the product backlog allows you to maintain that enthusiasm. You should be, like the way that Andy was capturing features even though they filled outside goals, you want to keep the flow of enthusiasm happening, you're capturing that lightning, and then you're just putting it on a shelf until such time as you can deal with it. So, there's no need to throw up road blocks. It's better to document and capture, put it in the backlog and then figure out when and where. And that's a really great point. You know, just as far as powering the client, now we have a process in which if they have request, you can put it in there and then are they going to prioritize it when it comes to the next sprint? Let's talk about what makes sense. So it is kind of all about empowerment with that. Whereas before, in that waterfall process, it was like, whoa, we already finished that. Now you're adding something new. We can't go and do that. That's gonna have a major ramification on all the stuff that we just figured out. So, it makes it much more flexible and innovative. So this is kind of backlog view of Unfuddle, which is one of the tools that we use. This is another tool, Jira, which is very popular as well. Both kind of end up using, depending on projects. There's other ones out there, and there's quite a list. And so, a lot of times you might have one that you kind of start to become familiar with, sometimes working with a client team internally they may have a favorite of theirs, so, it does take a little bit of back and forth to understand the nuances of those products. But, this is something that's worth kind of exploring, especially since as a designer I never thought I would ever need to be in a tool like this. (laughter) I'm like, are you kidding me? Like, what am I, what's happened, you know? And it just kind of shows how things blend together, and you want to be in that tool. You're gonna wanna have a voice in that tool, and working with your team. You don't want to be sheltered from the hard decisions. Like, you, I also appreciate several resolutions of task manager. We may mention Trillow in a later segment, again, it's really low resolution, it's a simple cards on a stack. The UI is super clean. But it will only satisfy small projects. Exactly. And as projects began to grow, I need a task manager project tool that's gonna sort of do this and help me manage more. But again, mobile first thinking, start with the simplest thing depending on your skill level and expertise, and grow into the tools that your team or project needs. Yeah, exactly. Like Trillow is a great on if you need something a little more light weight, it's a little easier to kind of grasp, and also does a similar types of things, so definitely worth exploring. So now, let's quickly talk about roles. So within the scrum process, we have some very key roles that are worth exploring. The first is the product owner. So this is gonna be a role that is on the client side. If you're part of an internal team, they'll also likely still be an owner type of role. They're very engaged and they're kind of responding to kind of the shifting nature of new things that come up. So, you know when we were talking about fallowing a plan versus adapting to change? In my mind, this is what I think about it. Stay-colders just kind of simply follow a plan, where product owners that are invested, they're helping you as a team, respond to that change. So they're gonna help to find the features, they're gonna help to decide on the release dates, they're responsible for the ROI, you know the Return On Investment, they are trying to kind of basically work with you as a team. And ultimately they get to decide if it's good or not. They're accepting or rejecting. So that's kind of the other thing. They're kind of doing that. And they're representing the voice of the entire client side, right? So whereas we were kind of working earlier as the ministry of space, and you guys were the stake holders, one of the key things I would have wanted to know, is who is ultimately going to be the product owner that's kind of on the day to day. It's on the day to day. You guys all won't be, you're gonna be, it's too big of a team to make that happen, it's unrealistic, but you will wanna kind of make sure you have a conversation early about who is the product owner. So anyone, the Scrum Master, and this is now the team side. Right, so they are kind of the person that represents the management of the project. They're going to be putting the scrum values and practices in place, you know, some of the different ceremonies that weren't gonna talk to next, they're the ones that kind of run the show, right? And they, I really like to think of them as the glue between the client and the team, and they're really making sure that everything is on track. What they also do is kind of make sure that they protect the team, because the idea is if you are in the middle of a sprint, then ideally you don't bother the developers. They know what they have to do for that sprint. So they're trying to shield the team a little bit from what needs to be done for that sprint. Now we have our team. So, team size can vary a little bit, five to nine people. Five to ten, we can round it up a little bit, make it easy, right? (chuckles) Nine, nine's cool. Alright, alright, nine. So they're cross-functional which essentially means lots of different skill sets. Programmers, testers, user experience designers, visual designers, all coming together for this this parallel development. Ideally, they're full time only because then they're truly committed, that sounds, that's ideal. Sometimes it doesn't always happen. But also, self-organizing. So the idea is that there's not suppose to be such a strict hierarchy, everyone's kind of figuring out what they need to do, and just starting to do it. There's not like this, has to be this one way, and that's one kind of organizational hierarchy. And then if you do need to change members, then try to make that happen in between sprints. Because it's gonna be too much wrap up time to jump into the middle of a sprint, try to figure out what's going on, it's just going to add a lot of risk to try to meet those sprint goals. So now we have ceremonies. What are the ceremonies that are really critical within this process? First one is sprint planning. We talked a little bit about this. So, we had that big giant backlog of all this stuff, all these user stories and epics, right? Well, one of the ones that we're gonna wanna go and tackle for that next sprint, so one of the ones that we also can commit to completing for that sprint. So this is how the backlog is created and continues to get updated. Tasks are identified and they're also estimated in terms of how much effort that's going to take. Now, some people call it in terms of hours. Other people will use, they'll measure it in terms of something a little more abstract like, apples, or you know, tickets, or excuse me, tickets is a bad one actually, apples, let's go with bananas, Points? Points is a better one. That is where I was going, yes, exactly. So points, right? So measure in terms of points. It makes it a little more abstract so it's not kind of, like one point is one hour. It allows a little more flexibility knowing that certain developers might be quicker, certain designers might be quicker than others, so it's trying to like estimate it based on that level of effort. Ultimately though, it's collaborative. The scrub master is leading the planning, but it really is kind of working with the team to decide all of these things and kind of figure it out together. Yeah What would be the typical, you know, the length of sprints? Two weeks is what we like to do, so we like to do two week sprints, sometimes it can go up to even a month, but that always seems really long. Like, you want to be able to kind of move faster, and then kind of see, and do smaller chunks if that's the case, and then kind of see where you're at and then adjust, you know, if you imagine the life cycle of how much time you have on a project, if you're doing month long sprints, then that's very few sprints. What's really helpful is like, time is organized fairly organically, so yeah, like a week. I will do sprints as short as a week. And I will have two meetings with the team per week. So again, I organize around that five day structure of the week, and it depending on the complexity, one to two weeks is pretty reasonable. It depends on the aggressiveness, how fine grain the detail is. And at what stage of the product you're in. Your sprints at the beginning, might actually be really short like one week ones, just to generate a bunch of ideas. And then you hit this development stride, and you're like okay, we need this three week, four week period of time. And then you back off a little bit and let stuff happen. That's a good point, you might want to have a week sprint, that's just like hey we're gonna test the proof of concepts. We just want to see, like, is this thing that we think is really critical, let's just do a little bit of experimentation really quickly and just see if it's possible and then at the end of that, it's gonna help inform other sprints. So then you have what's called a daily scrum. And so this is really, a daily check in with the team. This is basically, really quick, they're also known as daily stand-ups because the idea is you're suppose to stand up, you're not trying to sit down because then you make them take longer. So by standing up it keeps it short and sweet as possible. Ideally they're no longer than 15-minutes. And it's not about trying to solve the problems of everything. If there's some kind of issue that's come up, the daily stand-up is not where you're gonna try to address it. What you will do is identify if there are break-out meetings that need to happen, so that way you can best organize your time, right? The way it works, is there are essentially three questions that everyone answers. What did you work on yesterday? What are you working on today? Do you have any blockers? If there's any blockers, then that's likely something that the scrum master will help try to unblock, or you might have to talk to another team member. But it's important to understand why can't you complete this for tomorrow, what's holding you up? So it creates that transparency. This is one of my favorite methods that I use just globally within whatever team I'm working on as well as per project. We do this at Mr. Machine, we do this at Mr. Machine, and I do this at Exogee everyday with the team, the immediate project I'm working on, we meet daily. On a weekly basis, we as a whole team get together and do a larger scrum process. What I love about this, is that it's, you're just sort of checking in, and again, a lot of it isn't even blockages, as much as keeping on your radar how busy is this other person? If I need something, from a selfish standpoint, can I ask this person for a favor? Or no? They're working on three things. I've got to ask somebody else. Again, it keeps your empathy radar in check, and just on a regular basis we actually include some personal notes in scrum too. Because we aren't just things that make things. So real life intervenes as well. So we like to include that stuff as well as far as knowing everyone's bandwidth and being aware of what the team can do. Yeah, that's a great point. So for a favorite medium, we very much embrace the idea of the stand-ups. So, every morning we have our local Oakland team stand-up, which is basically just our team in the US. We all kind of just quickly go through that exact same thing, you know, what did we work on yesterday, what are we working on today, do we have any blockers? And then at 6pm, we have a design specific one, where we kind of meet with our design team. Because we have designers in Soul, Singapore, Dallas, and Oakland, and so we all just get together and go through the same process. So our design team is aware of what we're all working on. And then, usually later at night, because of how remote we are and distributed, and just the time zones, then we'll have project stand-ups where we go through the same type of process. And what's important for us when it comes to the project ones, we want the product owner to be on those. The more involved the better. We're not trying to hide stuff. We're trying to be transparent. We're trying to let them know what's going on. Because there's no point in revealing stuff. The more they're involved early on, the more they have a sense of what's happening. Yeah, again I will talk about this more in a later segment about designers working with developers. But this is critical as far as now that you're in the browser events, in the not, not necessarily in your comfort zone of graphics application, you need, the closer in proximity you are, not geographically, but in that mindset, the better off the whole product is going to be. So it's an indispensable part of the project. So then another ceremony is called the sprint review. Which is a little bit of what you were talking about. So, you know, basically at the end of each sprint, you have, it's also called a demo. You're just kind of demoing what was completed. The whole team can participate. It's suppose to be really informal, just like this is where we at. So usually it's just going to review did we meet the sprint goals? And things like that. And then there's another one called the Sprint retrospective and this is a little different. So although it happened at the end of the sprint, this is really kind of trying to address as a team, what's working, what's not. How do we shift? Is there anything we need to fix to keep up that momentum? How do we make sure that the sprints are working as efficiently as possible. Maybe there's an issue where designers can't keep up. The design team is somehow blocking the developers. Who knows what, we don't have the information from the client, so that's a way we can talk about how to make things more efficient. So now I want to talk a little bit about the designer's role. Let's specifically talk about how we can kind of dove tail into this process. This is always a question. Whenever I talk to people that are using Agile and they have design teams, I'm always like how do you work, how do you kind of dove tail with your team? So we found is we typically try to work a sprint or two ahead of sprints to make sure that the design team isn't blocking stuff. Because we're having to often iterate, we've having to work with the client, collaborate, understand, if it's something that they agree on and want to move forward, and so it's usually by working a couple steps ahead, it allows us the time to go thorough that process so we can make sure that the tickets, even though they may be written, they may not have all that content that needs to be flushed out yet because it's not quite ready. So this allows us the time to go through that process. It also allows, as designers, we want to make sure we're getting input and feedback from the developers. Just like, have them take a quick look just involving them so it's not just throwing stuff over the wall and keeping them as in the loop as possible. I think that we're also really trying to make sure that we're getting stake-holder approval as best as possible. Trying to set everything up. So whatever that approval is, and again, hopefully it's pretty light weight and it's not this big massive deal. But you're kind of keeping them in the loop. I mean like, okay, are we ready to go this. We want to hand this over, our sprint is coming up, this is scheduled to be for this sprint, we need to make sure it's in a good place and you're giving it the go ahead. And then we also want to have the designers do an overview of the approved designs, kind of flipped those a little bit. But just making sure that they're walking through, like, hey here's what we've created so far, kind of do a little bit of this is is where we're at, just to make sure everyone's on the same page. All about communication. So, a lot of the designer's role is going to really be about communicating with the developer to set up the entire team for success. And so when they get into their sprints, they're not surprised by something, like whoa! What is this? I've never seen this before. We talked about stand-ups. It's great to have designers on the stand-ups. Sometimes, there's quick little things that you can just answer very quickly. Save you so much time; by not having them part of that then, it's just gonna make things be very inefficient. And then just make sure that it's always clear what the most recent, accurate, up-to-date designs are. Sounds very obvious, but it's amazing when all of a sudden you have all of these different versions, final final, final final two, and all of a sudden they're working off of an old design. And there's certain ways that we'll talk about that can make that a little easier, but just something to kind of keep in mind that's your responsibility. Now, as you're going through things, and you're not only trying to work a sprint ahead, the other thing you're trying to do, is make sure if they have questions, or issues, or something comes up, that you're able to solve those problems. So sometimes it's gonna be about having a discussion with the developer. Should I try to mock something up? Or should we just kind of quickly talk about, get on the same page, and then let the developer run with it, right? And don't always assume that you should mock it up. Sometimes, that's completely overkill. Other times, it's really just gonna be easier to do that, because somethings just not being communicated clearly. So, as you kind of learn more about your team, and the strengths and weaknesses, you're gonna kind of figure out what some of the right approaches as those things come up during the sprints. The other thing is, trying to make sure that the designer's getting all the assets ready. And this is something as we started talking about, images, images alone. So we talked about potentially needing different sizes for different break points. You know? That kind of stuff. So, just making sure that's all good to go. Otherwise, they're gonna just use the one that they have. Just a quick note here, both of these first few points, we'll collect a lot of these tickets again in the backlog. And we have a system where we understand that a lot of these begin to go together, so we'll sort of organize them together, and we understand that if we sat down, and then worked side-by-side, we could get all twelve of these done in about 30 minutes. Yup, exactly. And that's gonna take experience with the person you're working with. There's certain things they can do, there's certain things you need to mock up, like Andy's saying. But there's some that falls kind of in between place like, it would just be faster, if we sat next to each other and nudged it together. But we wait for those things to stack up, and go okay, let's do this. Just before this workshop the other day, I sat down and did something, very much like all the image slicing. We walked through all 12 of the graphics sizes that were prepared. We made an inventory of all image assets that were needed. Looked for duplication. He got signed off having what we needed. And we immediately inputted those values into the system. If he, if I would have take the time to make all my components match as the designs were changing, I would have wasted time. If he would have tried to keep up with me, he would have wasted time. So we just called that question mark until the appropriate time and we were able to bang them all out. Exactly. Other quick things. Keep your site map current. Sounds easy. Sometimes things get out of whack. We'll talk a little bit about site maps tomorrow. But keep that as up-to-date as possible. And provide us with a style guide or component guide, another deliverable that we're gonna talk about tomorrow. And then just continue to know and speak the language. Build that vocabulary. Just keep doing that so that way you can kind of talk in the same way. So why don't I tell you a couple of dirty little secrets. Oohh! (laughter) Should we change the lighting in here? Yeah, I was gonna bring the lights down a little bit. So, we don't always include the reason when we write user stories. And so basically, what that means is, as a type of user I want some goal, and then like this whole like, so that some reason, we're kinda like, oh man! That's kinda tough to do all the time. Because of one they get repetitive. So you're like oh, you're writing the same thing over and over again, and two, you find that they're not always that needed. It's kind of like it just becomes a little bit of an effort where the person's just trying to think of it, just to fill out the formula. And you're like well, that seems a little unnecessary. And so, we try to include them at first, but then frankly sometimes we just stop doing that for some reason. And then the story writing process goes a little quicker. And then, this is the bigger one. Sometimes scrum is overkill. (explosion mock with mouth sounds) Right, and so what I mean by that, is you know, we just talked about all these ceremonies, we talked about all the people involved, and all the different kind of components to it. Sometimes, depending on the project, that's just gonna be more effort than it's worth it. Because the idea with scrum is that you're trying to build momentum with sprints. But depending on your team structure, depending on the size of the project, it might be better to kind of just like, bang through it, and just kind of figure out other ways. So you take the pieces that work. So you're still gonna wanna make it irritative. You're still gonna wanna make it collaborative. You're really just gonna kind of make sure that you're using the pieces that meet your needs. Quick example here, is this is using Invision, so this is using an Android app, and internal thing that we're kind of mocking up and basically the idea is it's just a simple app that's gonna allow you to turn off all your messages, so that way you can kind of, be in in focus. Because if you have an Android phone, lot of things to buzz all the time, gets a little annoying. So this kind of blocks that out so it's not happening. So, this way what we still want to do, is kind of work in iteration but we were just able to put all of the tickets right on top there in Invision. They actually have Dev Notes built into it as one of the ways to communicate that the client can't see. So very quickly, we were able to like, boom, here it is, it's simple enough, we don't need to go through this big giant process. Done. Simple. I actually had a question about when you're doing, when you're assessing whether something's successful, relating to the user. And then you say oh we want to do this, but we're not quite sure, how do you usually work that into the scrum process, like, how do you do the user testing. Sure, yes. Frankly, a lot of the user testing really depends on budget, right? And it sounds great to be like, we're gonna do user testing all the time, usability testing, but really, I think the idea is to have conversations with your client, to understand when you can go, and just get some feedback. So, I think it's really at what point that it's something that you want to test an assumption, and you want to validate that assumption. That's gonna be kind of like, an important moment to decide. Like, how much effort should we put towards this? Versus you know what, there's a certain amount of structure stuff that needs to be in place, let's keep going until we feel like it's a little more ready. But, you know, the more, certainly the more you test, the better, yet there has to be a certain amount of experience in place. Otherwise it's going to be so out of context, it's gonna be hard for them to know how to respond. And that's why also, you can use things like Invision, to test certain assumptions before you even get into code. So you can kind of do some key flows and just test if people are able to find them. So you don't have to wait until you're in the browser necessarily to test certain things. Basically, there's a whole team member, that's why we listed it as something else like the scope, it's a whole science within itself. Evaluating the impact of certain user needs on certain features and then giving a weight a gravity to specific stories, if he... That's just a whole thing that again, would bring us to a third day. But it's a really good question, lots of resources available. I think there are some articles in the additional resources that you can check out.