Strategy and Planning: Epics, Features, Stories and How to Predict UX Design Work

Hey everybody, okay, so in this video I want to go over strategy and planning, and this is figuring out the work that we're gonna do and why we're gonna do it. So initially, right now I have this, this is Azure DevOps, it's brought up, you can see, I mean, this is customizable, but let's go to our boards and look at our backlog. And in our backlog you can see there are a bunch of epics. I've got it sorted by by epic. And what an epic is— that's our first, our first bullet point here— is what is an epic? And according to Scaled Agile Framework, an epic is a container for a significant solution development initiative that captures the more substantial investments that occur within a portfolio. And I know that's a bit of a mouthful. And just to tack on to that, portfolio epics are typically cross-cutting typically spanning multiple value streams and program increments, PIs. So really, just to make that easier, it's, it, it's a group of features. It's, it's some kind of scaled amount of, of work, or, you know, basically like it says, a significant solution development initiative. So some kind of grouping of work that's going to be done. And now, how you define this, that's where things get interesting. There's some information that goes into it like the entry date, the name, the owner, the description, the business outcomes, the leading indicators, non-functional requirements. And there's usually an owner that is responsible for working with the product and solution management and system architecture engineer to split the epic into features or capabilities during backlog refinement. And what that is, is basically there's information about the epic, uh, including what we're trying to do, like what this epic is supposed to be, uh, what we're trying to measure within this epic, and what are some leading indicators of success or failure, uh, in terms of the hypothesis that we, we have around it, as well as some non-functional requirements. So let's look at an epic. Uh, the first one we have here is this MVP, which contained a bunch of features including explore users, explore recipes, explore meals, explore ingredients, export tags, follow, activity profile management, recipe management, meal management, and saved post management. This was the MVP for an app I actually have developed. It's called Wheat. It is a recipe and restaurant recommendation community platform that allows people to basically upload information around food or recipes and share it with other people. You can also follow users and things like that, and it allows you to share recipes and your orders. And, you know, so I launched this, I launched this app and got it out there, got some feedback, and now I want to start initiating that feedback. And you can see actually in this, this backlog, I have a few substantial areas that I want to do, including the initial MVP. Which is actually closed. You can see all of the, um, all the features have been closed. So this is actually closed. So we can close this because it is done. The only reason I actually still have it not closed is because once we refresh, it's hidden. That's like an Azure DevOps thing. But you can see it's gone now. So now we have version 1 responsive MVP. And what this is, is taking what was in the MVP and developing a responsive version of it, including the exact same features, but based on some of the research that happened in the initial launch, there were some, some things we wanted to do. So before getting into, into what goes into this, I wanted to talk a little bit about the discovery research that went into why we want to build this. And so we released the app version on iOS and we received some feedback. Users saw value in the app but experienced some pain points. Uh, there was inputting lots of information, uh, for recipes and that was difficult. There was desire for additional information. They were confused about the differences between recipes, meals that were ordered, and meals that were cooked. And they were not able to share with people who do not have the app downloaded. So our plan is to create a web responsive version of the app with the same feature set with some updates in the experience. We believe that by having a responsive version in general, it'll be low effort because we will reuse the same backend. It'll just be a responsive version. It'll also help with some of the complex information set for recipes, such as typing out descriptions and things like that. Because it's, it's on the web, you can access it on a computer that'll allow you to use a keyboard, things like that. That being said, we created the MVP Epic version 1. You can see we've already created that Epic. And we can fill out some of that information. So the funnel entry date, which is a start date, we're gonna do it January 1st, 2023. That's the start date for when this epic is gonna start. And I chose that date because that is actually the beginning of a new PI, program increment, and that will be Q1. So I have mine based on quarters. So Q1, we're doing the start of the MV— version 1 responsive MVP. The name is version 1 MVP responsive, MVP responsive. The owner is me, Ritzy Williams. The description is the web implementation of the MVP native experience, responsive version of the initial feature set for WHEAT. The business outcomes, we are looking to increase adoption. Oh, increased adoption allows for enhanced monetization when implemented. So right now we don't have monetization, but when we are going to implement it, having more users will allow that to start generating more revenue. So some of the leading indicators are new users created, recipes created, and page views of recipes. Page views. So now that we have that, let's take a look at our feature set. So from here we have user profile, we have recipe management, we have saved management, meal management, and order management. We are missing one more, and that is connect with friends. So when, when we do this, we normally prioritize them based on weight is shortest job first. So that goes through the amount of effort versus the amount of business value. And so we can figure out which we can build that offers the most value for the least amount of effort. So if it's, if it's gonna bring in a lot of revenue and it's easy to build, we'll prioritize that versus something that has low value and is very difficult to build. And that'll help us start bringing more value incrementally and plan based on this. Now, because this is an MVP, all these features are required and necessary, but we may have some areas that we might need to leave out, such as order, order management, which is the experience around restaurants. We may say this is less of a priority than meal management. So for this, we really want user profile, connect with friends, recipe management, and saved management. Then we get into order management versus meal management. They're both about the same because they're both considered posts. And having built this, I have a little bit more knowledge so I can speak on the development aspect. But from the business value, The order management has been used and the meal management was confusing. So the hypothesis is that if we update the meal management, it'll get more usage. But I do think the order management in terms of business value has more value than the meal management. So let's fill one of these out. So I already have this one filled out, the user profile, and in the user profile, there's a problem, a benefit, and acceptance criteria. I'm actually missing a headline for our problem. Not required, but I like to keep some formatting. So you see problem, benefit, acceptance criteria, and you may have some notes. So looking at the user profile and what that is to me, like a user profile is when you create an account, right? When you sign up or log in, you need a profile in order to do certain actions, right? Creating a recipe, we need to know who it's associated with. Now you could not have that association, but then you would have to enter the same data you need to every time. Think of like if you used Amazon and you did not have a profile, you still would be able to buy stuff. You just have to enter your information and shipping information and details and credit card every time. Obviously, that's not the best of experience. So in order to help get people to use it more often and have a better experience when they're purchasing something so they could check out faster, we they save their information so that it can streamline that process. We're doing the same here. Allowing you to have a streamlined process will make creating recipes or meals much faster. That way you can also create a connect with user or connect with friends and things like that. So that's really what we're trying to do here. And so the problem is that users are required to associate themselves with certain actions. This is a problem because they have to continuously re-enter their information thus creating friction. If we can solve this, we will have higher user satisfaction, higher conversions when creating posts or interacting with other users. So what goes into that? If we design this, what needs to be there in order to say this is complete? And usually at the, at the feature level, this is high level. You will also have acceptance criteria in the story level, which we'll talk about next, which will have a very similar thing. It's what is this— what is the criteria for this to say it's accepted and/or completed? So the user needs to be able to create an account. The user needs to be able to access and update the information entered in their account. The user can follow other accounts. Now this, we actually have a Connect with Friends feature, so it's not part of this feature. Depending on how you create and scope these features, you may have more details, but we've broken it into two features so this can live without actually the connection with friends. The user can see associated posts, which are recipes, meals, and orders in their account, and the user can see saved posts. That seems like solid acceptance criteria. Basically, you can create or log into your account. You can create an account, you can access it via logging in, you can update it through your profile management or something, and then you can also see associated posts, uh, with this. Okay, so in this scenario, this is what is in our feature. Now ideally, we do this for every one of these features where it has a problem, a benefit, and some high-level acceptance criteria. So now that we've created this feature, we need to create stories for it. And what story— a user story is, is an amount of work that's done and scoped that someone is actually going to complete. There are two different kinds of stories, one based on tasks and one based on time spent. The difference is one's called the user story. That's the one that's based on tasks. An example is if we're gonna build a site, we need to create the front end, we need to connect the back end, we need to publish it, something like that, right? It'll have different tasks or front end QA and then accepted, who knows. For the UI design, like we actually have UI design stories in which it'll have, mobile layout, tablet layout, extended desktop layout, and a desktop layout. So we might have layout and prototypes for each of the breakpoints. That's currently how we run them, but they're, you know, it depends on, on what is required to complete the story. So in this scenario, we have enablers that are basically— we use the enablers for conceptual exploration. So we're going to spend, say, 2 weeks on trying to figure out what goes into this user profile, trying to figure out the information architecture, the flows, the concept, and how we think it should interact with the rest of the application. You might say 2 weeks, you might say we're going to spend 1 week on this and another week on that, and you, you put it into different sprints that are 2 weeks long, or iterations. So I've actually created a few stories that might be added into a feature. So if you see here, you can see the UX Enabler for discovery— for discovery, sorry, I was missing the Y there— for user research. And it's pretty empty, but you should have some description and acceptance criteria for what this looks like. Now, for the design phase and that conceptual phase, that's what we have right here: UX Enabler Lean UX User Profile. And that it's create a testable concept for the user profile feature. All right. So really the, the main goal or description of this task is to understand and create a concept that is testable and you can figure out around the user profile. And this may update. You may put more information about the user profile. You may break user profile into multiple sections or smaller stories if necessary. You may have User profile onboarding, user profile authentication, user profile manage profile. Depending on how you need to scope the work, you may break these into different stories. So each of these stories have some kind of acceptance criteria as we described, but in this, you need to update the information architecture, you need to create the user flows, gather competitive analysis, review the user research, and create a testable concept, which could be a wireframe or a prototype, but something testable. Maybe it's a paper prototype, maybe it's a Figma prototype, some kind of way to test the concept and figure out whether, uh, the— it's usable. So that being said, you'll go into the usability testing enabler, which you may break out if, if needs be. Like I said, it's the work. This— if it's going to take more than 2 weeks to do this in that story, maybe you break it into another one, which will also have a description and acceptance criteria. So in this scenario, we'll say test with 6 to 8 users, test usability with 6 to 8 users, analyze the results, um, update backlog Based on findings. Alright, so in this case, say we, we test it and it fails completely. We need to do another enabler. We'll need to add that to the backlog. Whether we move something out or do it again, that'll depend on the prioritization, but there may be another item added to the backlog. Maybe it's minor and we can just go into UI design. Nonetheless, the findings should influence what direction we take. And it could be proceed forward, it could be stop and reevaluate. That being said, say it does do well, it's completely usable, we— minor updates, we'll move into the UI design. And this is the, the basically the blueprint for what development is gonna, gonna build. So in this case, we'll say some of the acceptance criteria is, um, Figma files for Mobile layout plus prototype demonstrating flows. Demonstrating flows. And we have this for, let's say, 2 breakpoints, desktop as well. So we need to make sure that we have a Figma file with— that is usable for the development team, as well as a flow demonstrating it. We might also say update or add update design system components with new variations, something like that, depending. So now that we have this work, right, we've created the work, we've scoped it, we say this work right here I'm gonna— we've already said this is completed, and we're gonna— I'm gonna do the Lean UX Enabler. I'll say it's a— it's an 8, which if my capacity is at the default number, which is 8, that's about 2 weeks of work. Now I'm gonna work on this in iteration 1. So you can see we have an area of wheat, we have iterations, and we're doing in 1.1, starting on 1/1, which matches our epic start date. So now that we have this here, we know on January 1st— let's see, when is it? January 1st through January 14th, we should have a testable concept. During 1-2, if we're going to test this, we will do it during 1-2, which will be the 15th through the 28th of January. And depending on that, it will go into UI design. Now, we don't know if it's gonna go into UI design or not. If it does, then it will go into UI design. So now we can look at that sprint. We can see this. I like to use the backlog view instead of the task board, but right now we're in 1.1, which is the current iteration. It's actually not, it's, you know, when it happens. But you see we have that UX, Lean UX enabler, the user profile. Now I like to add tasks for this so that I know how much work, and you can actually see the capacity. But for this, we're gonna look at Review Research, and that's me. And we'll say this is gonna be one day. We schedule our work at 6:00, and in order to become more predictable, we'll try to get these realistic. So if this takes one day, That'll be fine. Now if we add our capacity, we can actually see this. So Ritzy is doing design. He has 6 days per iteration— 6 hours per day. And we can go back to our backlog and see I have 6. If I add this work details— so now that I've added the capacity per day, and it's January 1st through 14th, there's 14 days. I have 84 hours in total. Now I believe this includes the weekend, so there's a lot of hours. And I have 6 hours for this task here. If I add more tasks, so let's say concept— actually, let's say information Architecture. I'm gonna say that's gonna take a day. I'm gonna say outline user flows, and then we'll do plus drawings. We'll say this together will be 2 days. Oops, not completed. But the original estimate. So as you see, we're filling up our hours and we can track this. Now, based on what happens, this may go over, it may go under, but the overall goal is to become predictable in our hours and how to scope work. Say right now we have one enabler here. If I'm capable of doing two enablers, we'll start getting better. I'll finish this right here and have tons of time left and say, okay, let's bring some more stuff in. Or in the future, we'll just schedule two enablers or three, uh, relatively similar sized enablers. So that's kind of how the scheduling and planning works for this one. If we think there's more, we can move to the second iteration. Let's bring the usability testing into the first one. So we have it here, right? And we have no tasks here. Let's add some tasks. Let's say user interviews for me. We're going to say this is going to be 4 days. So we'll add that, we're starting to fill up, and we also need to analyze results. Analyze results for me, and we'll say that's going to take 3 days. Boom. So now Within this 2 weeks of work, we have a bunch of work done, assigned 66 hours out of 84. We can actually look at a burndown chart that says this is how the trajectory should work. As we progress, it should go downward. This is the remaining capacity. And then once the work starts, like right now hasn't started, it'll show the work counting down. And as I update the hours in the the task. So say I complete 2 hours here or 1 day. When I mark completed, it'll start showing a burndown chart and seeing the predictability. And that way we can become more predictable with scoping work. So that's, that's a little bit about the strategy, the planning, and how work gets assigned and figuring out the predictability of work. This is a more complex topic. I know there's, there's a lot we can go into this. This has all of Scaled Agile Framework. We didn't go into PI Planning or anything like that, but this is a high-level overview of how it, how it happens. A lot of UX doesn't cover this. This is a lot more project management, but as, you know, I've increased my knowledge of the UX and project management, I've— we've actually started managing work like this and it helps. It starts— you start doing work at a full feature level instead of little bits and pieces or individual UI components like pages. Which becomes problematic because you're not seeing a holistic experience. With this direction, this user profile, we're gonna be looking at signing up, logging in, getting to your profile and updating the information, what information's shown on the profile, a holistic experience that should be releasable by itself. You should be able to release this entire feature of user profile once it's designed and built by itself. Okay, well, let me know what you guys think. I know this is a lot. I hope this was helpful and I hope you guys like this. I'm gonna continue this series with actually designing in the next one the UX Enabler that we just went through. So thanks for watching and if you like this, make sure you subscribe, like, and share it with your friends. So, alright, thank you guys. Bye.