In the last episode, we talked about the brief. Now, it's time to talk about user stories. In that, let's imagine now you've had that meeting with the client. You have the scope in mind of what the project is. You've asked all your questions, you've taken frantic notes and you feel like you've a pretty good idea of what this is now.
Well, now it's time to start defining the features more formally. And that is in the form of a user stories. Now, that's different than a user scenario or user personas. These are different things. User stories comes from, the sort of wording of that, comes from what I believe an agile methodology. I don't think that it was used before agile. I came across it when I was a product owner and scrum master for an agency, and found that this sort of term, for me, coming from a design background initially, was a little bit confusing. Because I said, "What do you mean user stories? How is that?"
But it really kind of comes down to is features and tasks. That's what they are. They are features or you could say they are tasks. Tasks, meaning something that you have to do. And so when we talk about a user story, its base is written as who, what and why. And that's what I like to keep it very simple in this form. Let me make this larger as well. We'll say that this is just a 36. So who, what and why?
So who is this task or future for? What is the task or feature? And why is it that we need this task or feature? When we say we, that could be the user or that could be us, as someone who needs to create this. Let's give you a sample one, right?
In the case here of this fitness app, I need to, looks like, from what we asked all those questions, right? We're going to need a login. So as a user, meaning someone who is going to subscribe to this website essentially, going to add my exercises, I'm going to add my food and keep track of all of that. In order to keep track of that, I need to create a login. So, I could say who? We are of the user. What do they want? So, a user wants to log in. And we could say, "So that they can keep track of their data." That's probably the most compact here. So, user wants to log in so they can keep track of their data. So who it is? The user. What do they want? They want to log in and why? So, they can keep track of data.
Now, traditionally it's in the sentence form, but there's various ways of doing this. And people have their own sort of twist on this. What I found to be pretty effective, and what I do with my clients and with my students, is just saying who, what And why? And don't make it into a sentence. Sometimes it's better when it's a sentence. Sometimes it's not, and it's going to be somewhat of a preference for you. So, in the case of not being a sentence, it would just be user. I'll do these as separate. The what? Login page, which might be a little bit too specific already. But let me just bring this up here. A login page. And why? Keep track of data?
Now, is that a harder for you or easier? I don't know. That's a preference thing. Again, when you say it in a sentence, that feature is sort of very clear, but sometimes people will write their sentences where they're not so clear. You could say, "Well, that's not a very effective user story." And that's probably true. So if you do put it in sentences, make sure that the sentence is really clear on who, what and why. So that's our user story.
Let's talk about how we can organize these and how we're going to create all of these user stories. So, a super basic way to do this is Google Sheets. You can, of course, use Excel or numbers. Any sort of column based system you could go and create this with. Some people do it on the Whiteboard or on a piece of paper, just to get started. These should be really rapid fire. They should come naturally and they should come from you thinking through the process and thinking through the questions that you asked that client and thinking through your project, essentially.
So we can go and put it in this format very easily, right? User. I'll just copy what I need. Login page and keep track of data. So, hmm. Let me just... That's fine. We're going to come back to this anyways. So, user, login page, keep track of data. So who, what and why? There's our basics. If we didn't do it this way, we could address it in just a sentence and we could just list out every single sentence. Again, both are pretty effective and it's going to be determined on what your best sort of use case is.
Once I do a login page, something like that, there's other things that'll come to mind immediately. Like, if I have a login that means I have an email and I have a password. Or I might have a username and password. What do I do with that? And so, what I like to do is keep track of the fields. And what I mean by fields is any of the input fields or data that's being collected, I like to keep track of that in the representation called a model.
Now, this really comes from a development oriented perspective. And so, if I referred to this as my model and the model that I'm talking about would be a user model. I'll just say, user capital like that. And I'll make this a little bit larger so you can see this. And we'll say 24. So, there's our user. What are the fields that our user is going to have? So, my user is going to have a first name and my user is going to have a last name. And they're going to have an email. And they're going to have a password. And I probably need a "created at." So when the user was last created, and I probably need an "updated at." So when was that user last updated at?
I might do something like last logged in as well. Of course, this could go on forever, right? I might need, in our case, a bio. So, something where a biography, something they could write a little information about themselves. They're going to be on a social platform, right? This fitness app, so they're probably going to need an image field, but it's probably a little bit more than that. It's probably something called profile thumbnail.
So I can start to very quickly start listing out all the fields as I start creating my user stories. Right? So here, my login page, keeps track of my data. I know from that feature, these are some of the fields that I'll need. I'll need an email and I'll need a password. In addition to this, who? User, login page, keep track of data; I also need to register. And why? So I can create an account, right?
Well, if I go back into here, if I have a password, there's a chances are that I forget my password. So what I want? I want to reset my password because I forgot my password.
You can start by creating these and going over here and listing out all the fields. I can start to get a sense of how all of this is set up. What's all of this data and how it's all connected? The Google Sheet method, I would say, is old school. Though, it works and you can start to listen them out very fast, and it's great for collaboration. There are tools that are designed to do just this. And I want to talk about a couple of them.
One of them is Trello, and this is Trello here. Trello comes with boards. If you're not familiar with Trello, there's a series here on Code Time for Trello. Definitely check that out. You can make a... I'm going to just go through this very quickly so you get a sense of how Trello works. You create boards. Boards represent either a project, or I guess you could say a project. And you could have multiple projects essentially in a bigger scheme of things, right? So, it might just be something like our user stories are dedicated to one board. So, we have private and public and we can set a default image for one of these. So I'll just say fitness app, user stories. And I'll create this board.
And so you'll see now I'm in this board, it has this stock photography photo. On the side here I have a menu. So, if I click this and then show menu, I have some options. I'm going to change the background color just to a color right now. So, it's a little bit more straightforward. This first thing is a list and it acts like a column. And essentially, I just have lists of information. And so, what I can do here is maybe set up something like an inbox. And I can start to, in the inbox, start to list out all of my user stories. And again, these idea here is rapid-fire, try to get them out.
So let's say something like a user needs to log in, so they can keep track of data, of their data. Right? So I'll add that. I'm going to make this a little bit bigger so you can see it. There we go. And so I just click add card and I have a card. I can add another one. A user forgets their password, and excuse my spelling for these things. I have a horrible time of spelling things. User forgets their password and needs to reset it. And I'll click add card.
So now we have two that are done. And you'll see this user needs to log in so they can keep... I can click on these and inside I get a description field, I get comments so I can add people and they can give feedback on this exact user story or feature. On the side I can assign it to members. I can click labels here and I can set up labels or create new labels. I can set up a checklist. So that user story might be broken down into a couple of things that need to happen. So, I can put that in a checklist. I can set a due date and I can add attachments to this.
There's also these things called power ups. I'm not going to talk about that. Definitely check out the Trello series on here on Code Time, and I can do a lot more than what I'm going to cover. So that's the basics. Here's our inbox, and the idea is anything that you think of on your project, we can start to go and list these things out.
So I'm going to go ahead and put a couple more in and then, jump ahead. Okay. So I took a couple of minutes and I created some more user stories. I would say about three or four minutes. And so in about three or four minutes, I was able to create, I don't know, maybe 20 or so user stories. And I would say at about that rate is probably pretty good. So, we could say four minutes, 20 user stories as a ratio. Maybe it's five minutes, 20 user stories. Again, I think about as you get more and more and more and more, you're going to realize you have more and more and more and more scope. And when you have more scope like that, that means obviously a bigger project and more money and all of that, right?
So, we'll go through a couple of these, so that you get a sense of where we are at with the fitness app. And maybe these will be different than the ones you created, if you're following along with creating a fitness app. So a user needs to log in so they can keep track of their data. We went through a couple of those. I added a couple in here now. And again, they're rapid-fire, right?
So imagine something like this. I imagine you would end up with at least 500 user stories. So a user needs to see a page that lists all of the exercises they can do. So think about that. Imagine what that looks like in your head. What is that? A user needs to be able to... So, a user, they're at a page. I'm thinking about the URL. What does the URL say? It says exercises/ exercises. There's like a nav button maybe that says exercises. And then, I'm seeing thumbnails of different exercises. That sounds like it could be that. Again, this isn't really... This is the who and the what? But in the description, I tend to write the why.
So why do I need this feature essentially? So a user needs to be able to see exercises they'd done in the past. A user needs to create their own exercises. A user needs to be able to add food multiple times per day. A user needs to be able to remove food. A user needs to be able to track the food that they have eaten for the day in charts, maybe something like calories.
So, this is a lot of unknowns there, right? So we could say, because a user wants to be able to track calories, sodium, sugars, carbohydrates, water intake, right? I would make a user story for each one of those things. A user needs to be able to delete their account. That's important, right? I create an account, I want to be able to delete my account. A user needs to be able to search for other users. A user needs to be able to add another user as a friend. A user needs to be able to remove a user as a friend. A user needs to be able to message a user. A user needs to be able to see another user's exercises.
Now, there's this question here, when I think about that, right? Each one kind of leads to more user stories. If a user can see another user's exercises, are there exercises that a user doesn't want to share? Well, what would that mean? I would mean public versus private exercises. When I say a private exercise, meaning only I will see that exercise. I don't want to share that with anyone else. Maybe I have an exercise routine and it's my super secret exercise routine where I do crunches and abs. And then, I sprint a half mile, and in the order and the frequency or whatever that I do that in, I don't want anyone to know. So do I need public or private? So I would go and add another one.
Exercises, and I'll do that right now. Exercises, a user's exercises can be public and private. So, what does that mean, right? That means private exercises don't show up on the overall exercises page, where I might see all of the exercises from all users in the entire system. A user needs to be able to sort all users by rank. So, we talked about these badges here. Some users are going to be higher ranked than other users based on maybe how often they've used the system, or how many exercises or maybe how many likes one of their exercises gets. So here, something just came off, right? Users can like exercises, or an exercise, singular.
So, you can see this can get really crazy, really fast. And I actually really enjoy this part of it, the process, right? Creating user stories, because it makes me start to dream, right? I can imagine all these cool features that this thing is going to have, and there's no limit, right? It's completely limitless. Anything that you want to create and imagine, you make a user story for it. And it's created essentially, right? It's a dream now. It's part of your mind there.
So, you're going to have a lot of these and I mean, a lot of them. And you shouldn't stop yourself. This is the sort of dumping period where you're just dumping any idea or any feature that you can think of into the inbox here. At another point, we need to go through this and we need to sense what is what? And what's important and what's not important? What are we actually going to take on? What are we not going to take on?
And a methodology for that is called Moscow. And I want to talk about that in the next video.