Let's talk about organizing our user stories, using the MoSCoW methodology. What is the MoSCoW methodology? Let's just start with that. The MoSCoW methodology is a way of organizing your tasks so that you and your clients or any stakeholders can agree on the value of a given task or given user story. That's it in a nutshell.
Now, there's again, different processes and different ways that people do this. They also do it in different frequencies. I want to talk about that for a second, and I want to pivot to a different software tool. Let me jump to Jira Agile here. There are many tools to streamline this process of user stories and Agile methodologies.
I would probably say the biggest player in the game is Atlassian and they make a software suite called Jira. In particular, Jira Agile. I started using it about five or six years back and it was a little bit clunky then. Nowadays, it's pretty streamlined. Atlassian actually purchased Trello. Trello is now part of Atlassian.
Basically they talk about scrum and Kanban. I guess we should talk about those two here for a second. Agile tool for scrum here. These are scrum boards. You also have, if you scroll down, Kanban boards and I would say, how best to break this down. I'm going to try to break it down fast and quick, to the point.
You have this idea of Agile and inside that there is this notion of a scrum board and a Kanban board. A scrum board is probably the most traditional in that you have various columns. For example, to-do in progress, a code review, and a done. I would say scrum and Agile really comes from the developer world. A lot of design teams have also started using this because it works with obviously developers who need to build out those features.
Of course, startups used this a lot. With scrum board, you set, there's a process. We'll say, let's give you an example of a one-week scrum. A one week scrum is you will start at the beginning of the week and you, or maybe even Friday of the previous week, and you will go through the list of user stories and, at this point, let's say you have 500 of them. You will select the user stories that are most important for that given week based on your stakeholders or a product owner's perspective.
Basically saying, it's like, what's the most, imagine you have a client. The client's like, where's my features? You say to that client, well, we're going to do this feature, this feature and this feature. Then we have some smaller features we'll throw into the mix. Those will be in your to-do section. Then, the week will start and you won't be adding anything else into the to-do section, meaning you've planned your entire week now. What this allows is your developers or your designers, they can't get bombarded with client stuff or outside factors. They can only work on the tasks that they've been assigned for that week.
That allows you to actually predict or know what's going to happen that week and essentially wall up your team to prevent them from being attacked, I guess you could say. Then you would take something. For example, they give with the scrum board in the preview here to do in the in-progress. It'd be assigned to someone. They would take on that task. They would do that task. It would need to be reviewed by someone. Someone review it and then they put it into the done column.
The idea is you would get better at planning the number of user stories that you can take on in a given week or a two-week sprint. That would then protect your users. It would do all of that. You could deliver every two weeks a new set of features. The difference between that and somewhat of a, I guess we talk about this more loosely is Trello.
Trello, though you can set it up in the same sort of way. There's not this idea of a backlog or the tasks that I'm doing this week. Though you could do it like an inbox, right? That's of course acting like that. You get that flexibility. With Jira, they build in all of these different rules and logic and conditionals that you can set up and the tasks themselves, these cards. These are pretty, again, Trello's a fantastic tool.
It really, has quite a bit, and it's free. It's crazy. It's free. Where Jira is that sort of pro tool thing. It's going to give you a little bit more. It's going to give you more control over your workflow. You can set up these paths or channels in which something X needs to happen before Y happens before the next thing happens. Or it needs to get approved before it can be moved onto the next section. You don't get that control with Trello. Anyone can take the task here and put it into another section. For example, doing, and now it's in the doing section.
There's no logic to stop this from happening. Where Jira is going to set up rules where you can prevent certain things like that from happening. There's certain tasks or checks that need to be set for it. Okay. Just wanted to bring that up as far as tooling.
I have gone back and forth between Jira and Trello quite a bit. I find sometimes that I want more flexibility. Though I can get that flexibility with Jira, I like the instant flexibility of, I want a new board. I make a new board in Trello and I'm ready to go. It takes me a second. If I want to get rid of stuff, I can get rid of it. It's really loose.
Again, it has its place, Jira and Trello. Note that, if you go and you're starting to do Agile or Sprints at a company, they're probably going to be using like a tool like Jira or some other big competitor. I believe Microsoft has a product as well. You can also see that in GitHub. GitHub has a similar product that comes with your Git repo. You don't know what any of that is, don't worry about it. We're going to stick with Trello in this demo. There's that.
Now let's talk about MoSCoW. MoSCoW is must, should, could, and won't. Let me put that in here as columns so you can get a sense of how one way we can organize this. I'm going to zoom out a little bit and I'm going to set this as must, could, should. I reversed that. And won't. We'll put an apostrophe there, make it legit. All right.
Should is like that. So must make my screen a little bit bigger here so we can see everything. Close that. Must, should, could, and won't. Normally you'll see it as must have, should have, could have, and won't. The idea is we take our user stories that we created, and then there's hundreds of them at this point. We organize them by this must, should, could, and won't. Now, this is just one way you can go across this way.
Another way to think about this is to go in and set up labels. I can say something in this label, for example, this red. I could say that this is a won't and click save and I didn't assign it. I'll click labels and then click won't. You'll see that it says won't here and it shows up red. Then here, this task, I would go in here and I can edit this and I'll say should. Then I can edit green. Of course, you can change these colors as well. I'll say that this is a must.
All this really is, let me click on that label as well so we know it assigns. All of this is, is just a way for you to identify, you and your stakeholders and your client to identify what are the user stories that you actually want to move forward with. This is where things really get particular.
Let's say you're just doing this as a student project. You have a deadline, of course. Say you're on a 14-week or 16-week term. Well, you know your deadline. You know when you have to get this thing done by. If you're [inaudible 00:10:01] handing a website and you need to create the website, you need to plan, obviously plan the website, site maps, wire frames, briefs, mock-ups, prototypes, HTML, CSS, and JavaScript, and code all of that stuff out and design all of that.
You need to plan accordingly. In order to plan accordingly, you also need to control the amount of scope that you take on. You'll have to do all of those things, but you don't have to take on every user story. This is where it's really important. It's just as important to identify what's a must as what's a won't and sometimes won't doesn't mean like won't ever, it just means won't now. Won't now means because of the scope or because of the budget. Scope, time budget, all of those things related. You don't have time to do it. That's really important. You can use MoSCoW as a tool to make sure to your client that they understand the real scope of what's involved on the project.
I have multiple meetings with my clients that go through this and saying, go through this list essentially and say like, all right, these are the things. They'll say, no, no, I must have that. I must have that. I must have that. Then I'll say to them in turn, that's going to be X more money. Normally at that point, a client will say, do it because it really is a must to them, or they'll say, Whoa, okay, hey, hold on there Trevor. That hold on there Trevor means, I realized that's not a must to the client. That's maybe somewhere in these other areas.
You can also think about this as a scale of numbers. A must is a three, a should is a two, a one is a could, and a won't is a zero. Sometimes certain features or user stories will be more important than others at specific times. A bunch of ways you can do this. Again, this is a methodology. All that really means is it's a tool that you can use to apply to your users. That's it. It's a way of organizing.
You can also think as high, low, or no priority. They just named it MoSCoW. It's got a catchy name, I guess. We can take these things. For example, a user needs to be able to show search exercises. Is that a must? Well, the first thing I would ask the client is how many exercises are we going to launch the site with? If there's only going to be 10 exercises or 50 exercises, it probably doesn't need a search. If there's going to be a thousand exercises, you're going to need to search because you need to be able to organize that information. As I save this thing, one of the things that came to mind is, exercises should probably have categories.
Well, I'll need to make another user story. I would come down here and I could say something like a user needs to be able to categorize or add a category or add multiple categories to an exercise. There's another user story. It came organically like that. You'll start to go through one and realize, there's probably more things there. As you go through these, creating all of this.
If we go back to this one, a user needs to be able to search. I would say, well, that's a should, but maybe if you're not going to have the content, that's more like a could. I don't say that's a won't because if there's going to be a lot of exercises, I want to be able to search through them. It's not a won't. I put that in the could section.
Here's another one. A user's, I wrote uses. A user, but it should say user. A user exercises can be public and private. All right, let's try this one. Is this a must? I kind of made the case and I kind of made the case that, a user might have this really cool exercise routine and they don't want anyone to know about it, but that's definitely not a must. I can say that's a should, but in reality, I would say that's a won't.
The whole point is that we have more exercises and they're searchable. By making private exercises, that means there's not a lot of content that's going to show up in the search section, which means the site's not going to look as good. Because we don't have as many exercises. That's a problem. I'm going to put that in the won't. Now that's not like won't ever, because maybe later on we go and do this, but right now it's definitely not a thing. I wouldn't launch the site with this feature. I might be, let's say phase two or phase three. We say, we have so many exercises. Let's go and add this in.
Here's another one. Users can like exercises. Well, there's this whole social aspect of things. You want to get people to look at other user's accounts and follow them or add them as a friend or something like that. This liking is a way to identify which exercises are most important or better than other exercises. The system will still work without it. I think that's really a should to me.
Now, when you go through this, it's just me right now. I'm making the decisions, but you're going to have your client and you're going to have other stakeholders and they're going to sometimes have really strong opinions about what's a must or a should or a could. Most of the time, it's going to be you fighting them the must. Because they're going to say everything is a must.
That's you breaking it down really and saying, Hey, sometimes that's you standing there and setting hours next to this. You could use the label system as well to do this. Or you could do like we're using the labels here. I could set something up like, or I could put it in here and just put it right here. I could say that this is a two-hour. That means that this is going to take two hours to do that, to actually create that thing.
That might be two hours of design or maybe that's two hours of development, but you can look at that and say the time that that's actually going to go and take. You can also look at this and say that this is a really difficult task or a really easy task or mid. So that you actually get a sense of the value of these user stories. How difficult is it going to be?
Another way to do that as you can actually literally just put a cost next to this. Users can like exercises. I would say for a system like this, that probably would cost maybe on the cheap, maybe you can do this at $600. You do the database and you do your logic and your controllers and you create some views and you style it and you have a nice little design and functionality, probably $600. You have likes now on exercises.
Maybe you can do it for less, but I'm going to say that to a client. That's going to cost $600 to build that functionality. Well, now you can look at that. The client say, I don't want to pay the $600. They can do a different task, a different user story. All right. So that's MoSCoW. Organizing these things into these various sections.