Jour 41 Day 41 · vendredi 2 octobre 2026 Friday 2 October 2026 Méthodo Fondamental
Agile/Scrum tel qu'on le vit Agile/Scrum as actually lived
Sprint, daily, vélocité, rétro : ce que Scrum dit vraiment, ce qui déraille en entreprise, et ce qu'on attend concrètement d'un stagiaire dans une équipe agile. Sprint, daily, velocity, retro: what Scrum actually says, what goes wrong in real companies, and what is concretely expected of an intern on an agile team.
L’essentiel
Le manifeste agile (2001) tient en quatre valeurs : les individus et leurs interactions plus que les processus et les outils ; un logiciel qui fonctionne plus qu’une documentation exhaustive ; la collaboration avec le client plus que la négociation contractuelle ; l’adaptation au changement plus que le suivi d’un plan. La nuance que tout le monde oublie : le manifeste dit « nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers ». Agile ne veut pas dire « pas de process, pas de doc » — ça veut dire livrer souvent, en petits incréments, et ajuster à chaque boucle de feedback.
Scrum est le framework agile le plus répandu, et celui que vous croiserez en stage. Trois rôles : le Product Owner (PO) porte la vision produit et priorise le backlog — il décide quoi faire ; le Scrum Master (SM) facilite, lève les obstacles et protège l’équipe — ce n’est pas un chef de projet ; l’équipe de développement s’auto-organise et décide comment faire. Le tout rythmé par des itérations courtes : les sprints.
En entretien de stage, personne n’attend de vous une certification. On attend que vous sachiez décrire un sprint, expliquer à quoi sert chaque cérémonie, et surtout montrer les bons réflexes d’équipier : découper, signaler, demander.
Comment ça marche
Un sprint dure 1 à 2 semaines et suit toujours la même boucle :
Product backlog (priorisé par le PO)
│ sprint planning : l'équipe tire
│ le haut de la pile et s'engage
▼
Sprint backlog ──▶ SPRINT (1-2 semaines)
│ daily 15 min chaque jour
▼
Incrément « done »
│
┌────────────┴────────────┐
▼ ▼
Sprint review Rétrospective
(démo du produit (améliorer le
aux parties prenantes) process d'équipe)
└──────── on repart ──────┘- Sprint planning — l’équipe choisit les éléments du backlog qu’elle pense pouvoir livrer, les découpe en tâches, et se fixe un objectif de sprint.
- Daily — 15 minutes debout, chaque jour : qu’est-ce que j’ai avancé, sur quoi je pars, qu’est-ce qui me bloque. C’est une synchronisation d’équipe, pas un rapport au chef.
- Sprint review — on montre le logiciel qui marche aux parties prenantes, on récolte du feedback. Une démo, pas un PowerPoint.
- Rétrospective — l’équipe, entre elle, regarde son propre fonctionnement : ce qui a bien marché, ce qui a frotté, une ou deux actions concrètes pour le sprint suivant. C’est la cérémonie la plus importante — c’est là que l’équipe s’améliore.
Les story points estiment la complexité relative d’une user story (souvent en suite de Fibonacci : 1, 2, 3, 5, 8…), pas des heures. La vélocité — le total de points livrés par sprint — sert à l’équipe à prévoir ce qu’elle peut embarquer. C’est un outil de prévision interne, rien d’autre : dès qu’on compare les vélocités de deux équipes ou qu’on en fait un objectif, les estimations gonflent et la métrique meurt (loi de Goodhart).
💡 Le daily sert à débloquer, pas à rapporter — si votre daily ressemble à une file d’élèves récitant leur journée au manager, il est cassé. Le bon signal : quelqu’un dit « je bloque sur X », quelqu’un d’autre répond « je te prends 15 min après ». Le daily crée des conversations, il ne les remplace pas.
Concepts clés à maîtriser
- Scrum vs kanban — deux façons d’organiser le flux :
| Scrum | Kanban | |
|---|---|---|
| Rythme | Sprints à durée fixe | Flux continu |
| Rôles | PO, SM, équipe dev | Aucun imposé |
| Engagement | Périmètre du sprint | Limite de WIP (travaux en cours) |
| Métriques | Vélocité (points / sprint) | Lead time, cycle time |
| Changement de priorité | Attend le sprint suivant | À tout moment |
| Adapté à | Développement produit planifiable | Support, ops, flux entrant imprévisible |
- Definition of Done (DoD) — la checklist commune qui définit « fini » : code écrit + testé + relu en code review + mergé + déployé en staging, par exemple. Sans DoD, « c’est fini » veut dire dix choses différentes pour dix personnes — et le sprint « fini » explose en recette.
- User story — un besoin exprimé côté utilisateur : « En tant que ⟨rôle⟩, je veux ⟨action⟩ afin de ⟨bénéfice⟩ », complété par des critères d’acceptation testables.
- Découper une story en tâches — la compétence numéro un du stagiaire. Une bonne tâche : une journée max, testable seule, livrable indépendamment :
Story : « En tant qu'utilisateur, je peux réinitialiser
mon mot de passe par email. » (5 points)
Tâches (≤ 1 jour chacune, testables séparément) :
- [ ] POST /password-reset : générer un token
expirable (1 h), stocké hashé # back
- [ ] Envoi de l'email avec le lien # back
- [ ] Page « nouveau mot de passe » + form # front
- [ ] POST /password-reset/confirm :
valider le token, mettre à jour le mdp # back
- [ ] Rate limiting sur les deux endpoints # sécu
- [ ] Test e2e du parcours complet # QA- Le kit du stagiaire — ce qu’on attend vraiment de vous : savoir découper une tâche floue en sous-tâches d’une journée ; dire au daily (ou avant !) quand ça bloque, sans attendre la veille de la démo ; demander de l’aide au bon moment — la règle classique : 30 à 60 minutes de recherche sérieuse, puis on sollicite, avec ce qu’on a déjà essayé.
En entretien
« Raconte-moi un sprint type dans ton projet. » — Déroulez la boucle avec du concret : planning (« on a embarqué 3 stories, ~20 points »), daily, un blocage et comment il a été levé, la démo en review, une action sortie de la rétro. Le concret prouve que vous l’avez vécu, pas juste appris.
« À quoi sert le daily ? » — À synchroniser l’équipe et surfacer les blocages tôt. 15 minutes max, pas un rapport au manager. Bonus : dire qu’un blocage annoncé au daily du jour 2 se règle en une heure ; le même découvert au jour 9 fait rater le sprint.
« C’est quoi la vélocité, et à quoi elle sert ? » — La somme des points livrés par sprint. Elle sert à l’équipe à prévoir sa capacité. Elle ne mesure pas la productivité, ne se compare pas entre équipes, et ne doit jamais devenir un objectif — sinon les estimations gonflent.
« Scrum ou kanban pour une équipe de support ? » — Kanban : le flux entrant est imprévisible, un sprint figé n’a pas de sens. On limite le travail en cours (WIP) et on mesure le temps de traversée. Scrum convient mieux au développement produit planifiable.
« C’est quoi une definition of done ? » — La checklist partagée qui rend « fini » objectif : testé, relu, mergé, déployé. Elle évite le faux-fini qui explose en fin de sprint.
🎤 En entretien — « Raconte-moi un sprint qui s’est mal passé » est une question piège inversée : l’intervieweur teste votre lucidité, pas votre perfection. Structure gagnante : le contexte (« on avait embarqué trop de points »), le signal raté (« un blocage tû jusqu’au jour 8 »), ce que la rétro a changé (« on a ajouté une limite de WIP et un point mi-sprint »). Un candidat qui n’a que des sprints parfaits à raconter n’a jamais fait de Scrum.
Pièges & idées reçues
⚠️ Le cargo cult agile — faire toutes les cérémonies sans les valeurs : des dailys sans entraide, des rétros sans action, des sprints qui n’adaptent rien. L’équipe « fait du Scrum » et livre comme avant, avec des réunions en plus. Les cérémonies sont des outils au service du feedback ; vides, elles ne sont que du théâtre.
- Le daily de 45 minutes — devenu réunion de statut déguisée, chacun attend son tour en regardant son téléphone. Remède : 15 minutes chrono, les discussions de fond se prennent à deux après.
- Les sprints mini-waterfalls — spec la première semaine, code la deuxième, tests « au prochain sprint ». On a découpé le waterfall en tranches de deux semaines, pas fait de l’agile. Un incrément doit être done — testé inclus — à la fin du sprint.
- La vélocité comme flicage — dès qu’un manager compare les équipes ou exige « +10 % de points », les estimations gonflent en silence. La vélocité est un outil de prévision de l’équipe, pour l’équipe.
- Le SM chef de projet — un Scrum Master qui assigne les tâches et demande des comptes n’est pas un SM, c’est un chef de projet renommé. L’équipe s’auto-organise ; le SM déblaye.
- « Agile = pas de doc, pas de plan » — le manifeste privilégie, il n’élimine pas. On documente ce qui sert, on planifie à l’échelle d’un sprint et d’une roadmap — on s’interdit juste de croire un plan figé à six mois.
Pour aller plus loin
- Le manifeste agile et ses 12 principes — 5 minutes, à lire en entier
- Le guide Scrum officiel — 13 pages, la source à citer en entretien
- Henrik Kniberg, Scrum and XP from the Trenches — le Scrum vécu, pas le Scrum théorique
- Henrik Kniberg, Agile Product Ownership in a Nutshell — 15 minutes de vidéo, la meilleure explication du rôle de PO
The essentials
The agile manifesto (2001) fits in four values: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. The nuance everyone forgets: the manifesto says “while there is value in the items on the right, we value the items on the left more”. Agile does not mean “no process, no docs” — it means shipping often, in small increments, and adjusting at every feedback loop.
Scrum is the most widespread agile framework, and the one you’ll meet during your internship. Three roles: the Product Owner (PO) carries the product vision and prioritizes the backlog — they decide what to build; the Scrum Master (SM) facilitates, removes obstacles and protects the team — they are not a project manager; the development team self-organizes and decides how to build. All of it paced by short iterations: sprints.
In an internship interview, nobody expects a certification from you. They expect you to describe a sprint, explain what each ceremony is for, and above all show good teammate reflexes: split, signal, ask.
How it works
A sprint lasts 1 to 2 weeks and always follows the same loop:
Product backlog (prioritized by the PO)
│ sprint planning: the team pulls
│ from the top and commits
▼
Sprint backlog ──▶ SPRINT (1-2 weeks)
│ daily, 15 min each day
▼
"Done" increment
│
┌────────────┴────────────┐
▼ ▼
Sprint review Retrospective
(product demo to (improve the
the stakeholders) team's process)
└──────── start again ────┘- Sprint planning — the team picks the backlog items it believes it can deliver, splits them into tasks, and sets a sprint goal.
- Daily — 15 minutes standing up, every day: what I moved forward, what I’m on today, what’s blocking me. It’s a team sync, not a report to the boss.
- Sprint review — you show working software to stakeholders and collect feedback. A demo, not a PowerPoint.
- Retrospective — the team, among itself, looks at its own way of working: what went well, what created friction, one or two concrete actions for the next sprint. The most important ceremony — it’s where the team improves.
Story points estimate the relative complexity of a user story (often on a Fibonacci scale: 1, 2, 3, 5, 8…), not hours. Velocity — the total points delivered per sprint — helps the team forecast what it can take on. It’s an internal forecasting tool, nothing more: as soon as you compare two teams’ velocities or turn it into a target, estimates inflate and the metric dies (Goodhart’s law).
💡 The daily is for unblocking, not reporting — if your daily looks like a line of pupils reciting their day to the manager, it’s broken. The good signal: someone says “I’m stuck on X”, someone else answers “I’ll grab you for 15 minutes after”. The daily creates conversations, it doesn’t replace them.
Key concepts to master
- Scrum vs kanban — two ways of organizing the flow:
| Scrum | Kanban | |
|---|---|---|
| Cadence | Fixed-length sprints | Continuous flow |
| Roles | PO, SM, dev team | None imposed |
| Commitment | Sprint scope | WIP limit (work in progress) |
| Metrics | Velocity (points / sprint) | Lead time, cycle time |
| Priority changes | Wait for next sprint | Any time |
| Best suited to | Plannable product development | Support, ops, unpredictable inflow |
- Definition of Done (DoD) — the shared checklist defining “finished”: code written + tested + code-reviewed + merged + deployed to staging, for instance. Without a DoD, “it’s done” means ten different things to ten people — and the “finished” sprint blows up in acceptance testing.
- User story — a need expressed from the user’s side: “As a ⟨role⟩, I want ⟨action⟩ so that ⟨benefit⟩”, completed with testable acceptance criteria.
- Splitting a story into tasks — the intern’s number one skill. A good task: one day max, testable on its own, deliverable independently:
Story: "As a user, I can reset my password
by email." (5 points)
Tasks (≤ 1 day each, separately testable):
- [ ] POST /password-reset: generate an
expiring token (1 h), stored hashed # back
- [ ] Send the email with the link # back
- [ ] "New password" page + form # front
- [ ] POST /password-reset/confirm:
validate token, update the password # back
- [ ] Rate limiting on both endpoints # security
- [ ] End-to-end test of the full flow # QA- The intern’s toolkit — what’s really expected of you: splitting a fuzzy task into one-day subtasks; saying at the daily (or before!) when you’re blocked, without waiting until the eve of the demo; asking for help at the right time — the classic rule: 30 to 60 minutes of serious digging, then ask, bringing what you already tried.
In an interview
“Walk me through a typical sprint in your project.” — Unroll the loop with concrete details: planning (“we took on 3 stories, ~20 points”), the daily, one blocker and how it was lifted, the demo at the review, one action out of the retro. Concrete details prove you lived it rather than just studied it.
“What is the daily for?” — Syncing the team and surfacing blockers early. 15 minutes max, not a report to the manager. Bonus: point out that a blocker raised at the day-2 daily gets solved in an hour; the same one discovered on day 9 sinks the sprint.
“What is velocity, and what is it for?” — The sum of points delivered per sprint. It helps the team forecast its capacity. It doesn’t measure productivity, doesn’t compare across teams, and must never become a target — otherwise estimates inflate.
“Scrum or kanban for a support team?” — Kanban: the incoming flow is unpredictable, a frozen sprint makes no sense. You limit work in progress (WIP) and measure lead time. Scrum fits plannable product development better.
“What is a definition of done?” — The shared checklist that makes “finished” objective: tested, reviewed, merged, deployed. It prevents the fake-done that explodes at the end of the sprint.
🎤 In an interview — “Tell me about a sprint that went wrong” is a reverse trick question: the interviewer is testing your lucidity, not your perfection. Winning structure: the context (“we took on too many points”), the missed signal (“a blocker kept quiet until day 8”), what the retro changed (“we added a WIP limit and a mid-sprint check”). A candidate with only perfect sprints to tell has never done Scrum.
Pitfalls & misconceptions
⚠️ Cargo cult agile — running all the ceremonies without the values: dailies without mutual help, retros without actions, sprints that adapt nothing. The team “does Scrum” and ships like before, with extra meetings. Ceremonies are tools in the service of feedback; emptied out, they’re just theater.
- The 45-minute daily — turned into a disguised status meeting, everyone waits their turn looking at their phone. Remedy: 15 minutes on the clock; deep discussions happen in pairs afterwards.
- Mini-waterfall sprints — spec the first week, code the second, tests “next sprint”. You’ve sliced waterfall into two-week chunks, not done agile. An increment must be done — tests included — by the end of the sprint.
- Velocity as surveillance — the moment a manager compares teams or demands “+10% points”, estimates quietly inflate. Velocity is the team’s forecasting tool, for the team.
- The SM as project manager — a Scrum Master who assigns tasks and demands accountability isn’t an SM, it’s a project manager with a new title. The team self-organizes; the SM clears the path.
- “Agile = no docs, no plan” — the manifesto prioritizes, it doesn’t eliminate. You document what’s useful, you plan at the scale of a sprint and a roadmap — you just refuse to believe a plan frozen six months out.
Going further
- The agile manifesto and its 12 principles — 5 minutes, read the whole thing
- The official Scrum Guide — 13 pages, the source to cite in an interview
- Henrik Kniberg, Scrum and XP from the Trenches — Scrum as lived, not Scrum as theorized
- Henrik Kniberg, Agile Product Ownership in a Nutshell — a 15-minute video, the best explanation of the PO role