what is scrum it is the systematic customer resolution unraveling meeting that just doesn't really mean anything to me so in this video i thought i'd explore exactly what scrum is when it comes to agile projects how people are implementing it into startups and programs and why it replaced the traditional waterflow method of creating projects let's get started scrum is basically a type of project management that allows you to create and deliver projects faster especially in spaces like startups and software development where we need to move and change quite regularly in the last five to ten
years it's been adopted all over the place but some people don't really know exactly how it works or how to implement it properly so in this video what i'll be doing is two parts the very first part will be describing exactly what scrum is we'll go through the whole scrum workflow including all the main parts of it such as the roles and artifacts and ceremonies and how an entire sprint looks like and how to run sprints as well then after that we'll implement it with a project that i'm using so you can see what it
looks like in practice i'm creating a figma board here which you guys will have access to which i'll be using as part of this scrum demonstration and what we're going to do is create a scrum workflow this workflow are the core aspects to create your own scrum if that's what you're planning to do there are a few elements to the scrum workflow so let's take a look at them the very first is the product backlog the second is the sprint planning next you have the sprint backlog then the sprint and the potential product and finally
you do a sprint review now it's fine if you don't understand what these things are we'll get into these but the end process should be between one to two weeks whenever you're doing a sprint like this but sometimes they can also last one to four weeks as well so let's actually dig into what each one of these are and how they work because they make up the essence of the scrum workflow and all of them work a little bit different the first thing that we'll need to know is that there are three different roles when
we're doing scrum the very first role is the one for the product owner this is the person who is creating it maybe the company maybe the organization maybe the idea holder themselves the next is the scrum master this is someone to help you organize and manage your scrum sessions they might not be a product owner they might not be a developer usually there's someone in between that can sort of work as a middle person and basically communicate everything that's happening and finally you have the team members themselves these are usually the designers or the developers
or the people working on the actual product itself it's important to define the different types of roles here because some will attend certain aspects of scrum while others you'll want to avoid having in certain meetings and i'll get into this a little bit later but for the time being just be aware of these three roles the next thing we want to take a look at is the three artifacts of scrum these are something a little bit different so let me get into exactly what an artifact is and why it's a part of scrum now the
very first type of artifact is the actual product backlog the next is the sprint backlog and finally we have the burnout chart now the product backlog is sort of like the features of the products things like logins or admin dashboards or anything like that the sprint backlog is sort of turning these features into user stories that can be developed and the burn down chart is where we have a look at all the user stories and then have a look at how many are complete how many are left to do and gives you an indication of
how long it'll take to complete the project now let's move on to ceremonies these are basically like events that are happening in scrum and there are three main types the very first is the sprint planning this is where you plan the project sprint for the one to four weeks the next is the daily scrum where you're reviewing what has been done so far and the final one is the sprint review which you do at the very end of a sprint to have a look if everything that we planned was completed there are also a few
terms and definitions that we'll be using inside of scrum so let's have a look at defining these so that you have a better idea of what they are and what they do the first most important is the definition of done this is an important one because this is basically the definition of when a story has been completed there's also the term water flow something i'll get into a little bit later but traditional waterfall is basically like the old way of doing projects as opposed to using scrum next we have stand up which is part of
ceremonies and talking about how you do your meetings and we also have user stories this is probably a very important one where it basically defines how a feature is to be implemented in a scrum methodology so let's jump in and have a look at traditional water flow development as opposed to scrum development these are two very similar yet different ways of creating a project if you've done traditional development in software you have probably been using the waterfall method without even realizing it this is where significant time and effort is spent into building a project in
several phases the first phase is usually the planning phase where we create the plan and overall objective for a project then we build the project and finally we test and release it now all of these steps happen sequentially and they can happen over a long period of time sometimes over three to six months and in software development that can be very long this is where scrum basically flips this on its head turning this sort of a structure into a one to four week structure in small units so instead all these elements here overlap into what
we call a sprint instead of trying to complete an entire project just core aspects of a project whether it would be an mvp or a product is implemented in these steps which we'll be having a look at very shortly but this sprint is then done continuously so that if we need to change the project at any point in time if there are any failures they can be identified very early on and this allows you to pivot a project or change it or modify it depending on how you need these micro releases are a variation of
what we would normally do as a macro release in traditional water flow this is just a brief idea of the differences between the two types of project methodologies but hopefully it gives you a small insight into what we'll be looking at next which is what a traditional sprint looks like and how we create one so let's take a look at that now in scrum the first thing you want to do is create a project backlog and then a sprint planning session now for the project backlog this is where you write out all the project features
that need to be implemented you'll want to turn these into user stories and this way you'll be able to essentially create a map of all the different tasks that need to be done this is why it's called a project backlog so for example a login feature could have a number of user stories for these you have a certain syntax you need to follow now this syntax is as a blank i need to blank so that blank you need to fill in the blanks in this type of format to have a very well defined user story
based on what you're trying to implement this user story can be considered here for this login features as as a user or as a general user i need to log in so that i can access the website's backend this is an example of a login story for a user as part of the login features a login might also have a number of user stories so for this login feature we might have a forgotten password story in this case a general user would say as a general user i need to reset my password so that i
can still log in if i forget my credentials now these are just two examples of user stories you could have quite a few depending on the feature that you're building out normally you want to connect them so you understand exactly what you're building who for and why but once you do this you have a nice product backlog for your scrum board that you can start using as part of the sprint planning now the sprint planning is a little bit different this is where you start taking in multiple project backlog scopes and creating more or less
a priority list of what you need to do so if we were for example filling out this product backlog inside of scrum we would have basically the entire product and all its features are listed out as deliverables that need to be attended and these would all be created into user stories this way you can drag the user stories across to the spring planning to identify exactly what you're building so another example of a product backlog feature here would be an admin dashboard so the user story might go something like as an administrator i need to
access the dashboard to view reports on users another could be maybe something which is less important such as reporting so as a admin i need beautiful graphics with maybe bar graphs in order to quickly access and understand the data now when we move on to sprint planning this is where we basically rank the most important and high priority items to be added to sprints in the terms of a login being able to log in is more important than being able to reset a password or for the admin dashboard being able to access it is more
important than having maybe some beautiful graphics or statistics so sprint planning is basically encapsulating the most important aspects here and once we have this we can start arranging what the plan is for the sprint ahead now the sprinter head is normally performed when you do a sprint backlog this is where if for example you've already completed srimt or you have one upcoming you take a look at the objectives that needs to be done such as if there was anything missing in the previous strint and just how much you can complete in a single sprint during
the one to two week period a good rule of thumb is often to take on board only 85 to 115 percent of how much work you actually think you can complete in a sprint backlog so now that we have all the essentials we can now perform a sprint we would utilize the sprint backlog as the plan for the sprint and here we would complete the sprint in a quick number of phases where we're doing all the planning building testing and deployment of the features based on those user stories once we complete that we update a
burn down chart this is a chart of the entire product backlog as well as all the tasks that have been completed so far to give you a graphical representation of how the progress of the project is going how many user stories are left and when the estimated time for the product will be complete now we can move on to a sprint review having completed a sprint and finishing the task involved basically the sprint review is where the product owner as well as the scrum master and maybe the developers review the entire project at the end
of the sprint now this is different as opposed to say a daily scrum which is more akin to just the team meeting up with the scrum master in order to view the progress so far on a daily basis normally you wouldn't have the product owner involved in the daily scrum because obviously it's not a review it's just a summary of the day now all of these tasks basically done in a sequence and repeating constantly encapsulates scrum and how it's used in software development when you're coding when you're building software developing it whether you're designing it
scrum can come in handy in order to help you better plan for that one project i'm working on right now is a pricing calculator and it's one that i'm doing inside of editor x as well as in node.js and i've got a figma board so let's have a look at how i can incorporate an example of scrum so that you can actually see it in practice so what i've got here is a brand new document and i'm going to also link this in the description below similar to what i'm going to do with the scrum
board so that you guys can copy these at any point in time and reuse them the first thing i want to do here is define the project for this project here i'm creating a pricing calculator so the definition of the project will essentially include the fact that i want to create three or four different types of pricing calculators where people can for example put in whether they do hourly uh fixed or even value-based pricing and utilize this calculator to define the price that a website might cost let's figure out the scrum template here of how
we'll be doing this systematically the very first thing we want to do is create the project features these are the features that will make the project possible so these will be like creating the calculator itself or having the page in figma or in editor x the next thing we want to do is create a sprint planning session but before we can do that we need to create the user stories based on the features that we're creating from the project backlog and finally what we're going to do is make sure to actually perform a sprint now
the sprint in my case will probably happen every week but it depends on the size of the project and how many features you're completing i wouldn't recommend anything above three weeks because you might find that you get yourself trapped in a progress loop where you're not actually finishing off all the sprint tasks that are needed now there are three main types of meetings that i want to apply for this the very first is the daily scrum this is where you check in with yourself or others to basically cover the progress that you're doing so in
this case i'll be checking in with just myself to make sure that i'm on track to building this pricing calculator the next thing we'll need to do is a sprint planning session and in this session we're going to have a look at exactly what i want to do this week of course building a pricing calculator won't take a single week and instead we need to define exactly what tasks want to be completed at what week now right now there'll be lots of tasks and even just building out one aspect of a task might not be
that simple because a useless story that might for example involve getting the price for an hourly based website might require a back-end api a front-end ui and much more the final thing here we'll create is the sprint review now this meeting in itself is basically at the end of the session so this could be for me for example at the very end of the week where i can review exactly what i did for this sprint session and it can also be with the project owner which in this case is just me as well now i'm
going to define how long the sprint should take here at the very bottom i'm just going to do one to four weeks but in my case it will just be the one week great so we've got all the summary here for the scrum session i want to create next let me create the backlog here the project backlog of the task that i want to do now i'm going to try and define this project backlog with sort of the features i want to complete and in this case there are three main features and these are the
types of pricing calculations i want the very first is the pricing based calculation the second is the fixed base pricing and the final one is the hourly base pricing but before i can complete these i will need to make sure that i have a general application that works i also need some micro tasks because these are sort of very high-end project features and here is where i can start creating some stories based on these features these user stories i'll be dragging along to this prints later on so let's define these really clearly i'm going to
give each one a bit of a title so that we can reference it properly and i'm also going to place it in alignment with the other content that i'm creating let me create one here for the general calculator because i think that also needs its own number of stories and here i'm going to start off with a design story now this design story will be to basically have the user interface for the calculator and the story will go something along the lines of as a user i want to see a calculator that i can use
to get the pricing for a website so here i'll define that as is there are a heap more tasks so let me just go through and create them right now these will include things like creating the user interfaces creating the functionality both on the front end and the back end creating some of these things inside of figma or editor x and then putting it all together the end result here is that we'll have a backlog which basically is the entire project as it needs to be completed which is perfect this can be refined over and
over if you really need but normally once you've defined this you want to keep it more or less the same with this done we can now look towards the sprint planning session as well as the sprint backlog now the sprint planning session will involve looking at all the tasks and selecting the most important to prioritize for the sprint run these are the tasks that i'll be doing during the week and these are the tasks that are achievable in that week too i just selected three main ones here which is a little bit of ui a
little bit of one pricing calculation which is maybe hourly pricing or value based pricing and then i'm going to put this into the sprint backlog now the backlog is looking at a little bit of what has done in the past if there's anything left over as well as what's going into the sprint ahead and the next thing we need to do is create the sprint itself a sprint can look very much like a trello list you can define it a little bit however you want but i like the idea of a trello list where you
have items that are to do that are in review and are complete so i'm just gonna drag these across so that we can have a look at them in depth another thing to note is that sometimes a single user story can be broken into more granular parts and this is useful especially if you're trying to define a sprint and the tasks that are required so in this case for the value based pricing task i can break this into a figment design as well as then an editor x design that will be converted as well as
a backend api that needs to be created in order to achieve all of this now in terms of this there are some things that i've already done and some things that are still left undone so i can drag them into the correct place such as the figma page design is something i've already completed so i should be able to simply drag and drop that into the right hand side panel here and so the basics of a sprint are here ready to go we're going to have a look at this maybe i'll continue to update this
as we're building other projects so that if you guys want to take part and join in then you can do so too i hope you guys enjoyed this video and learned something new scrum is pretty cool and this pricing calculator i'm putting together should be pretty useful too especially calculating the price of a website if you want to help me with some user stories feel free to join the discord below check out this scrum board i've put together and pull out a user story and give it a shot otherwise i'll see you in the next
one thank you
