Name: Intro to Scrum in Under 10 Minutes
Uploaded: 2017-03-19T16:07:59.000Z
Duration: 8 min 53 s
Description: Thousands of YouTube videos with English-Chinese subtitles! Now you can learn to understand native speakers, expand your vocabulary, and improve your pronunciation...

My name is Hamid Shojaee, and I've been involved with a number of software development projects

at a number of different companies, and I've come to recognize 'Scrum,'

as one of the best agile development practices in use today.

I want to show you why Scrum is so great, and how you can get started with Scrum in

like product backlogs, team roles, sprints, burndown charts, and more.

So get ready to be bombarded with information.

Lets say THIS is the product we want to build.

For this product, we get all kinds of feature requests from customers, executives, or even

In Scrum, features are written from the perspective of the end-user,

therefore, features are known as user-stories.

The collection of all these user-stories is called the product backlog.

Another way to think of the product backlog

is to think of it as a wish list of all the things that would make this product great.

Once we have our wish list or the product backlog,

we need to start planning which specific user-stories

we're going to put into a particular release of our product.

we need to have one or more people in our team who are going to play a variety of roles.

and helps make sure the right features make it into the product backlog

representing the users and customers of the product.

She helps set the direction of the product.

He is the Scrum Master and his job is to make sure the project is progressing smoothly

and that every member of the team has the tools they need to get their job done.

He sets up meetings, monitors the work being done and facilitates release planning.

He's a lot like a project manager, but that's such a boring title.

So, we'll call him a Scrum Master [Karate yell] to imply he knows some Jui-Jitsu.

And the rest of the team has similar roles to other development processes.

while these guys test it to make sure it works right.

These guys use it, and hopefully pay for it.

And these guys, they generally get in the way, but it turns out you can't build many

But lets get back to this: Release Planning.

To plan a release, the team starts with this, the product backlog,

and they identify the user-stories they want to put into this release.

These user-stories then become part of the release backlog.

The team then prioritizes the user-stories and estimates the amount of work involved

Sometimes larger user-stories are broken down into smaller more manageable chunks.

The collection of all the estimates provides a rough idea

of the total amount of work involved to complete the entire release.

There are a lot of techniques for creating good estimates.

Some prefer estimating in story points where estimates are made

relative to building a small component with a known level of difficulty.

Unfortunately, story points don’t answer the question of,

I have found that the best technique is to estimate work in hours,

but to use some standards in how estimates are done.

For example, things that take less than a day to complete

will be estimated as 1 hour, 2 hours, 4 hours or 8 hours.

Every item will fall into one of those buckets.

There will be no 3 hour estimates, for example.

A 3 hour item would fall into the 4 hour bucket.

Larger items will be estimated as 2 days, 3 days, 5 days, or 10 days.

Again, all estimates in between will fall into the next larger bucket.

Extremely large items are similarly estimated in months: 1, 2, 3 or 6 Months,

but the reality is that such items will need to be broken down substantially

We’ll come back to these estimates in just a minute.

With a prioritized set of user-stories and the estimated amount of work at hand,

we are now ready to plan out several sprints to get the work done.

Sprints are short-duration milestones that allow teams to tackle a manageable chunk of

Sprints generally range from a couple of days to as much as 30 days in length,

depending on the product's release cycles.

The shorter the release cycles, the shorter each sprint should be.

And you'll want to have at least 2 to as many as a dozen sprints in a given release.

So, at this point, we can take our release backlog and split it up into several of these:

One of the most important things to remember about sprints

is that the goal of each sprint is to get a subset of the release backlog to a ship-ready

So, at the end of each sprint, you should have a fully tested product with all the features

Since sprints are a very short, but a realistic representation of part of the product,

a late finish of the sprint is a great indicator that the project is not on schedule and something

Therefore, it's extremely important to monitor the progress of each sprint with THIS:

The burndown chart is the number one reason for Scrum's popularity,

and one of the best project visibility tools to ensure a project is progressing smoothly.

The burndown chart provides a day-by-day measure of the amount of work that remains in a given

In this graph, you can see that the amount of work remaining bounces up and down from

Subtitles ListPlay Video

Intro to Scrum in Under 10 Minutes

entire

extremely

essential

prioritize