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