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:14for
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:36difficulty
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:41member
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
00:08:42you
”