Press "Enter" to skip to content

Intro to Scrum in Under 10 Minutes

00:00:03hi this is me my name is hameed Cho je

00:00:06and I’ve been involved with a number of

00:00:08software development projects over the

00:00:09years at a number of different companies

00:00:11and I’ve come to recognize scrum has one

00:00:13of the best agile development practices

00:00:15in use today in this fast-paced video I

00:00:17want to show you why scrum is so great

00:00:19and how you can get started with scrum

00:00:21in under 10 minutes I’ll cover all the

00:00:23core scrum concepts like product

00:00:25backlogs team roles sprints pronoun

00:00:28charts and more so get ready to be

00:00:30bombarded with information let’s say

00:00:32this is the product we want to build or

00:00:34this product we get all kinds of feature

00:00:36requests from customers executives or

00:00:38even other team members in scrum

00:00:40features are written from the

00:00:41perspective of the end user

00:00:43therefore features are known as user

00:00:45stories the collection of all these user

00:00:47stories is called the product backlog

00:00:49another way to think of the product

00:00:51backlog is to think of it as a wish list

00:00:53of all the things that would make this

00:00:54product great once we have our wish list

00:00:56or the product backlog we need to start

00:00:59planning which specific user stories

00:01:00we’re going to be putting into a

00:01:02particular release of our product but

00:01:04we’re getting ahead of ourselves let’s

00:01:05back up a bit to build this product we

00:01:08need to have one or more people on our

00:01:09team we’re going to play a variety of

00:01:11roles first we need her she plays the

00:01:13role of product owner and helps make

00:01:15sure the right features make it into the

00:01:17product backlog by presenting the users

00:01:19and customers of the product

00:01:20she helps set the direction of the

00:01:22product then we need this guy he’s the

00:01:24swamp master and his job is to make sure

00:01:26the project is progressing smoothly and

00:01:28that every member of the team has the

00:01:30tools they need to get their job done he

00:01:32sets up meetings monitors the work being

00:01:33done and facilitates release planning

00:01:35he’s a lot like a project manager but

00:01:38that’s such a boring title so we’ll call

00:01:39him a scrum master behind who knows some

00:01:41jujitsu and the rest of the team has

00:01:44similar roles to other development

00:01:45processes these guys build the product

00:01:47while these guys test it to make sure it

00:01:49works right these guys use it and

00:01:52hopefully pay for it and these guys they

00:01:54generally get in the way but it turns

00:01:55out you can’t build many products

00:01:57without them but let’s get back to this

00:01:58release planning to plan and release the

00:02:01team starts with this the product

00:02:02backlog and they identify the user

00:02:04stories they want to put into this

00:02:06release these user stories then become

00:02:08part of the release backlog the team

00:02:10then prioritizes the user stories and

00:02:12estimates the amount of work involved


00:02:14sometimes larger user stories are broken

00:02:17down into smaller more manageable chunks

00:02:18the collection of all the estimates

00:02:20provides a rough idea of the total

00:02:22amount of work involved complete the

00:02:24entire release a quick side note about

00:02:27estimates there are a lot of techniques

00:02:28for creating good estimates some prefer

00:02:31estimating in story points where

00:02:32estimates are made relative to building

00:02:34a small component with a known level of


00:02:37unfortunately story points don’t answer

00:02:39the question of when will my project

00:02:41ship I’ve found that the best technique

00:02:43is to estimate work in hours but to use

00:02:45some standards and how estimates are

00:02:47done for example things that take less

00:02:49than a day to complete will be estimated

00:02:51as one hour two hours four hours for

00:02:53eight hours every item will fall into

00:02:55one of those buckets

00:02:56there will be no three hour estimates

00:02:58for example a three hour item would fall

00:03:00into the four our bucket larger items

00:03:02will be estimated as two days three days

00:03:04five days or ten days again all

00:03:07estimates in between will fall into the

00:03:09next larger bucket extremely large items

00:03:12are similarly estimated in months one

00:03:14two three or six months but the reality

00:03:17is that such items will need to be

00:03:18broken down substantially before work

00:03:20actually begins we’ll come back to these

00:03:22estimates in just a minute but for now

00:03:24let’s get back to this the release

00:03:26backlog with a prioritized set of user

00:03:28stories and the estimated amount of work

00:03:30at hand we’re now ready to plan out

00:03:32several sprints to get the work done

00:03:33spreads are short duration milestones

00:03:36that allow teams to tackle a manageable

00:03:38chunk of the project and get it to a

00:03:40ship ready state sprints generally range

00:03:42from a couple of days to as much as 30

00:03:44days in length depending on their

00:03:45products release cycles the shorter the

00:03:48release cycles the shorter each sprint

00:03:49should be and you want to have at least

00:03:51two – as many as a dozen sprints in a

00:03:54given release so at this point we can

00:03:56take our release backlog and split it up

00:03:58into several these sprint backlogs one

00:04:00of the most important things to remember

00:04:02about sprints is that the goal of each

00:04:04sprint is to get a subset of the release

00:04:06backlog to a ship ready state so at the

00:04:08end of each sprint you should have a

00:04:10fully tested product with all the

00:04:11features of the sprint 100% complete

00:04:14since Sprint’s are very short but a

00:04:16realistic representation of part of the

00:04:18product a late finish of the sprint is a

00:04:20great indicator that the project is not

00:04:22on schedule and something needs to be

00:04:24done therefore it’s extremely important

00:04:26to monitor the progress

00:04:28each sprint with this a burn down chart

00:04:30the burn down chart is the number one

00:04:32reason for swans popularity and one of

00:04:34the best project visibility tools to

00:04:36ensure a project is progressing smoothly

00:04:38the burn down chart provides a

00:04:40day-by-day measure of the amount of work

00:04:42that remains in a given sprint or

00:04:43release in this graph you can see that

00:04:46the amount of work remaining bounces up

00:04:48and down from day to day but is

00:04:49generally trending towards zero because

00:04:52historical information is provided in

00:04:54the burn down chart it’s easy to see if

00:04:56the team is on the right track using the

00:04:58burn down chart the team can quickly

00:05:00calculate this the slope of the graph

00:05:02which is also called the burn down

00:05:03velocity this is the average rate of

00:05:06productivity for each day for example a

00:05:08team’s rate of productivity might be

00:05:10that on a typical day they finish

00:05:11approximately 50 hours of work knowing

00:05:14that it’s possible to calculate an

00:05:16estimated completion date for the Sprint

00:05:17or even for the entire release based on

00:05:20the amount of work remaining what’s

00:05:21great about the burn down chart is that

00:05:23we can compare our actual velocity and

00:05:25projected completion date to what the

00:05:27team needs to do in order to finish on

00:05:29time this is perhaps the most useful

00:05:31piece of knowledge that any team member

00:05:33product owner or product executive can

00:05:35have about the project because knowing

00:05:37whether or not the project is on track

00:05:39early in the schedule can help teams

00:05:40make the proper adjustments necessary to

00:05:42get the project on track the burn down

00:05:44chart provides empirical proof that the

00:05:46project is on track or if it’s going to

00:05:48be late so let’s talk a little about

00:05:50where the data for this incredibly

00:05:52useful burn down chart comes from as you

00:05:54recall part of the release planning

00:05:55process was to create an estimate for

00:05:57each user story in the release backlog

00:05:59the collection of these estimates for a

00:06:01given sprint represents the total amount

00:06:03of work that must be done to complete

00:06:04that spring as each team member goes

00:06:06through and makes progress on one or

00:06:08more of the user stories they simply

00:06:10update the amount of time remaining for

00:06:11each of their own items so the total

00:06:13amount of time remaining on the group of

00:06:15user stories that make up a sprint

00:06:16changes on a day-by-day basis hopefully

00:06:19going downward until it hits zero when

00:06:21the Sprint is complete the burn down

00:06:22chart aggregates the remaining work data

00:06:24and shows it visually it’s brilliant

00:06:27because it communicates a massive amount

00:06:29of information in just a few seconds and

00:06:30that brings us to this the daily scrum

00:06:33the daily scrum is an essential tool to

00:06:35having communication flow freely between

00:06:37team members the idea is to have fast

00:06:39paced stand-up meetings where team


00:06:41quickly list the work they have

00:06:42completed since the last meeting and any

00:06:45obstacles in their way by meeting daily

00:06:47it ensures the team is always in sync

00:06:48and any major issues are dealt with as

00:06:50soon as they are known finally as each

00:06:53sprint comes to a finish it’s important

00:06:54to have a sprint retrospective meeting

00:06:56where the team can reflect on what went

00:06:58right and areas of improvement after all

00:07:00scrum is a flexible agile development

00:07:02method that means constant improving and

00:07:04tweaking for every team so there you

00:07:06have it

00:07:07scrum in under 10 minutes you don’t know

00:07:09all the essential concepts to start

00:07:10implementing scrum inside of your

00:07:12organization but wait a second what

00:07:14about tools to help you implement scrum

00:07:15well it just so happens that I’ve spent

00:07:18the last 10 years building such a tool

00:07:20with a lot of help from these guides a

00:07:21group of genius coders and design

00:07:23engines the tool is called on time and

00:07:25it helps you manage your products your

00:07:28backlogs your team your releases and

00:07:30your sprints it gives you project

00:07:32visibility with burndown charts and

00:07:33always answers the question of who is

00:07:35working on what you can get started with

00:07:37it for free at access Ofcom of course

00:07:40you could use a giant whiteboard some

00:07:42note cards and a bunch of different

00:07:44spreadsheets to track everything you

00:07:46could also use an abacus instead of a

00:07:47calculator to do math but we’re getting

00:07:49a little off-topic so let’s quickly

00:07:51review everything in scrum you work with

00:07:54this a product backlog which is nothing

00:07:56more than a list of features that we

00:07:58call user stories you then break down

00:08:00the product backlog into one or more

00:08:01release backlogs and for a given release

00:08:04you further break up the release backlog

00:08:05into a number of sprint backlogs which

00:08:08are essentially short duration

00:08:09milestones throughout your project you

00:08:11then monitor the progress of each sprint

00:08:12using these or noun charts and have

00:08:15daily scrum meetings to ensure

00:08:16everything is on track after each sprint

00:08:19you have a retrospective meeting to

00:08:21fine-tune everything and if you want a

00:08:22tool to implement scrum you can use on

00:08:25time that will help you ship software on

00:08:27time that’s all there is to it oh and

00:08:29one last thing whether you loved or

00:08:31hated this video I’d love to hear from

00:08:33you you can reach me on twitter or via

00:08:35email if you have any feedback now get

00:08:38going create a great team collaborate

00:08:40and ship software on time