Pratique du Shadowing: Intro to Scrum in Under 10 Minutes - Apprendre l'anglais à l'oral avec la vidéo

Choisissez un mode d'entraînement

Chaque mode ouvre une salle d'entraînement en plein écran.

122 phrases

Si les phrases sont trop courtes ou trop longues, cliquez sur Edit pour les ajuster.

Hi, this is me.

My name is Hamid Chodjai

and I've been involved with a number of software development projects over the years at a number of different companies

and I've come to recognize Scrum as one of the best agile development practices in use today.

In this fast-paced video, I want to show you why Scrum is

so great and how you can get started with Scrum in under 10 minutes.

I'll cover all the core Scrum concepts like product backlogs, team roles, sprints, turn-down charts, and more.

So get ready to be bombarded with information.

Let's say this is the product we want to build.

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

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 be putting into a particular release of our product.

But we're getting ahead of ourselves.

Let's back up a bit.

To build this product, we need to have one

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

First, we need her.

She plays the role of product owner 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.

Then we need this guy.

He's 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 to imply he knows some jujitsu.

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

These guys build the product while these guys test it to make sure 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 products without them.

But let's 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 for each item.

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.

A quick side note about estimates.

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, when will my project ship?

I've 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 before work actually begins.

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

But for now, let's get back to this, the release backlog.

With a prioritized set of user stories and the estimated amount of work at hand, we're 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 the project

and get it to a ship ready state.

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 two 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, sprint backlogs.

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 state.

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

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 needs to be done.

Therefore, it's extremely important to monitor the progress of each sprint with this, a burndown chart.

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 sprint or release.

In this graph, you can see that the amount of work remaining bounces up and down from day to day, but is generally trending towards zero.

Because historical information is provided in the burndown chart, it's easy to see if the team is on the right track.

Using the burndown chart, the team can quickly calculate this, the slope of the graph, which is also called the burndown velocity.

This is the average rate of productivity for each day.

For example, a team's rate of productivity might be that on a typical day they finish approximately 50 hours of work.

Knowing that, it's possible to calculate an estimated completion date for the sprint, or even for the entire release based on the amount of work remaining.

What's great about the burndown chart is that we can compare our actual velocity

and projected completion date to what the team needs to do in order to finish on time.

This is perhaps the most useful piece of knowledge that any team member, product owner, or product executive can have about the project.

Because knowing whether

or not the project is on track early in the schedule

can help teams make the proper adjustments necessary to get the project on track.

The burndown chart provides empirical proof that the project is on track or if it's going to be late.

So let's talk a little about where the data for this incredibly useful burndown chart comes from.

As you recall, part of the release planning process was to create an estimate for each user story in the release backlog.

The collection of these estimates for a given sprint represents the total amount of work

that must be done to complete that sprint.

As each team member goes through and makes progress on one or more of the user stories, they simply update the amount of time remaining for each of their own items.

So the total amount of time remaining on the group of user stories

that make up a sprint changes on a day-by-day basis, hopefully going downward until it hits zero when the sprint is complete.

The burndown chart aggregates the remaining work data and shows it visually.

It's brilliant because it communicates a massive amount of information in just a few seconds.

And that brings us to this, the daily scrum.

The daily scrum is an essential tool to having communication flow freely between team members.

The idea is to have fast-paced, stand-up meetings where team members quickly list the work they have completed since the last meeting and any obstacles in their way.

By meeting daily, it ensures the team is always in sync

and any major issues are dealt with as soon as they are known.

Finally, as each sprint comes to a finish, it's important to have a sprint retrospective meeting where the team can reflect on what went right and areas of improvement.

100

After all, Scrum is a flexible, agile development method that needs constant improving and tweaking for every team.

101

So there you have it, Scrum in under 10 minutes.

102

You now know all the essential concepts to start implementing Scrum inside of your organization.

103

But wait a second, what about tools to help you implement Scrum?

104

Well, it just so happens that I've spent the last 10 years building such a tool, with a lot of help from these guys, a group of genius coders and design ninjas.

105

The tool is called OnTime, and it helps you manage your products, your backlogs, your team, releases and your sprints.

106

It gives you project visibility with burndown charts and always answers the question of who is working on what.

107

You can get started with it for free at Axiosoft.com.

108

Of course, you could use a giant whiteboard, some note cards, and a bunch of different spreadsheets to track everything.

109

You could also use an abacus instead of a calculator to do math, but we're getting a little off topic.

110

So let's quickly review everything.

111

In Scrum, you work with this, a product backlog, which is nothing more than a list of features that we call user stories.

112

You then break down the product backlog into one or more release backlogs.

113

And for a given release, you further break up the release backlog into a number of sprint backlogs, which are essentially short duration milestones throughout your project.

114

You then monitor the progress of each sprint using these, burndown charts, and have daily scrum meetings to ensure everything is on track.

115

After each sprint, you have a retrospective meeting to fine-tune everything.

116

And if you want a tool to implement scrum, you can use OnTime.

117

It'll help you ship software OnTime.

118

That's all there is to it.

119

Oh, and one last thing.

120

Whether you loved or hated this video, I'd love to hear from you.

121

You can reach me on Twitter or via email if you have any feedback.

122

Now get going, create a great team, collaborate, and ship software on time.

Télécharger l'application

Tout pour parler couramment

Prononciation IAChaque phrase notée

Phonétique (IPA)Maîtrisez chaque son

VocabulaireEnrichissez votre lexique

Jeu de vocabulaireApprenez en jouant

Scanner le QR

Download on theApp Store Get it onGoogle Play

FOR YOU

Vidéo recommandée

44 phrases

Vocabulaire et conseils d’expression pour cette leçon

Cette leçon d’expression orale de niveau C1 s’appuie sur la vidéo « Intro to Scrum in Under 10 Minutes ». Les mots qui reviennent le plus souvent : sprint, product, release, backlog, scrum. Cette vidéo contient 122 phrases et 1829 mots à répéter en shadowing. La partie parlée dure 8:38. Le locuteur parle vite, environ 212 mots par minute : attendez-vous à des liaisons et à des sons réduits. 84 % des mots font partie des 3 000 mots les plus courants en anglais ; le reste mérite d’être vu avant de commencer.

Vocabulaire clé de cette vidéo

Les 15 mots les plus avancés de la vidéo, avec leur prononciation et leur sens :

Mot	Prononciation	Sens
sprint nom	/spɹɪnt/	sprint
backlog nom	/ˈbæk(ˌ)lɔɡ/	arriéré
scrum nom	/skɹʌm/	scrum
bucket nom	/ˈbʌkɪt/	seau, chaudière
agile adjectif	/ˈæd͡ʒ.aɪl/	agile
manageable adjectif	/ˈmænəd͡ʒəb(ə)l/	maniable, gérable
prioritize verbe	/pɹaɪˈɒɹ.ə.taɪz/	prioriser
retrospective adjectif	/ˌɹɛt.ɹə(ʊ)ˈspɛk.tɪv/	rétrospectif
chunk nom	/t͡ʃʌŋk/	pièce, morceau
smoothly adverbe	/ˈsmuːðli/	souplement, doucement
milestone nom	/ˈmaɪlˌstoʊn/	borne, borne kilométrique
visibility nom	/ˌvɪz.əˈbɪl.ɪ.ti/	visibilité
calculate verbe	/ˈkælkjʊleɪt/	calculer
velocity nom	/vəˈlɑsəti/	vecteur vitesse, vélocité
graph nom	/ɡɹæf/	graphique

Les verbes à particule que vous entendrez

Mot	Prononciation	Sens
break down verbe		tomber en panne
back up verbe		reculer
break up verbe		rompre, couper
go through verbe		traverser
make up verbe	/ˌmeɪk ˈʌp/	constituer, composer
set up verbe	/ˌsɛt ˈʌp/	mettre en place, installer
stand up verbe		se lever, se mettre debout
turn down verbe		refuser, décliner

La grammaire de cette vidéo

Les structures que le locuteur utilise le plus, avec les mots exacts de la vidéo :

Structure	Dans la vidéo
Voix passive be + participe passé — l’accent est mis sur ce qui arrive, pas sur qui le fait	I've been involved · be bombarded · are written
Present perfect have/has + participe passé — une action passée qui compte encore maintenant	I've been involved · I've come · I've found
Propositions relatives who / which + proposition — une précision sur une personne ou une chose	graph, which is · backlog, which is · backlogs, which are

Prononciation à surveiller

Le locuteur utilise 16 contractions et formes réduites, comme I've, we're, we'll. Prononcez-les sous leur forme courte, telles que vous les entendez.

Mots longs — placez bien l’accent: manageable /ˈmænəd͡ʒəb(ə)l/, prioritize /pɹaɪˈɒɹ.ə.taɪz/, retrospective /ˌɹɛt.ɹə(ʊ)ˈspɛk.tɪv/, visibility /ˌvɪz.əˈbɪl.ɪ.ti/, velocity /vəˈlɑsəti/

Les sons difficiles pour les francophones :

/tʃ/ et /dʒ/ — à ne pas adoucir en « ch » et « j »: agile /ˈæd͡ʒ.aɪl/, manageable /ˈmænəd͡ʒəb(ə)l/, chunk /t͡ʃʌŋk/, jujitsu /ˌd͡ʒuːˈd͡ʒɪtsuː/, ninja /ˈnɪnd͡ʒə/
/r/ anglais — langue recourbée, sans frotter la gorge: sprint /spɹɪnt/, scrum /skɹʌm/, prioritize /pɹaɪˈɒɹ.ə.taɪz/, retrospective /ˌɹɛt.ɹə(ʊ)ˈspɛk.tɪv/, graph /ɡɹæf/

Comment s’entraîner avec cette vidéo

Écoutez la vidéo en entier une fois sans parler et notez les mots que vous ne connaissez pas.
Commencez à la vitesse 0,75×, répétez phrase par phrase, puis revenez à la vitesse normale quand cela devient facile.
Enregistrez-vous et comparez avec l’original, en faisant attention à des mots comme sprint, backlog, scrum.

Qu'est-ce que la technique du Shadowing ?

Le Shadowing est une technique d'apprentissage des langues fondée sur la science, développée à l'origine pour la formation des interprètes professionnels. Le principe est simple mais puissant : vous écoutez de l'anglais natif et le répétez immédiatement à voix haute — comme une ombre suivant le locuteur avec un décalage de 1 à 2 secondes. Les recherches montrent une amélioration significative de la précision de la prononciation, de l'intonation, du rythme, des liaisons, de la compréhension orale et de la fluidité.

Technique du shadowing : lire le guide complet étape par étape →

Pratique du Shadowing: Intro to Scrum in Under 10 Minutes - Apprendre l'anglais à l'oral avec la vidéo

Choisissez un mode d'entraînement

Télécharger l'application

Scrum Events

C++ in 100 Seconds

The Technical, Business and UX Skills Every Product Manager Needs

Introducing Automations: always-on coding agents

Everything we learned in 29 minutes at Harvard Business School (part 1)

How an Agile Coach can help Product Owners

On the Power of the 15 Minute Habit

How to build a startup in one month | Pieter Levels and Lex Fridman

Simon Sinek | Start with WHY to inspire action (Super Quick Version)

10 Usability Heuristics: From Theory to Practice | Course Preview

FREE 30 minutes Disciplined Agile Senior Scrum Master Overview + Q&A Session

Kubernetes Explained in 100 Seconds