Intuition The 30-second pictureOld software was built like a dam : design everything, build everything, ship once after 2 years — and discover the customer wanted something else. Agile says: build a stream of tiny working slices, show them constantly, and steer based on feedback. Scrum organizes this into fixed time-boxes called sprints; Kanban organizes it as a continuous flow with strict limits on work-in-progress. Both fight the same enemy: big batches of unverified work .
Intuition The core economic argumentThe cost of being wrong grows with how late you discover the mistake . If you plan for a year and ship once, a wrong assumption costs a year. If you ship every 2 weeks, a wrong assumption costs at most 2 weeks. Agile is a bet that feedback frequency > planning accuracy , because in software the requirements themselves change while you build.
The 4 values of the Agile Manifesto (2001) — each is "prefer LEFT over RIGHT", not "ignore right":
Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan
A lightweight framework where a small cross-functional team delivers a potentially shippable increment of product every fixed-length sprint (usually 1–4 weeks ), guided by 3 roles, 5 events (ceremonies), and 3 artifacts.
Definition The 3 accountabilities
Product Owner (PO) — owns the what and the why . Maximizes value by ordering the Product Backlog . The single voice for priorities.Scrum Master (SM) — owns the how the team works . A servant-leader who removes blockers and protects the process. Not a project manager who assigns tasks.Developers — own the how it's built . Self-organizing; they decide how much they can commit to and how to do it.
Common mistake "Scrum Master = boss / project manager"Why it feels right: they run the meetings and chase status, so they look like a manager.
The fix: the SM has no authority to assign work or set priorities . The team self-organizes; the PO prioritizes. The SM's power is influence + removing impediments. If the SM is telling people what to code, it's not Scrum.
Product Backlog — the ordered master list of everything the product might need. Owned by PO, never "done".Sprint Backlog — the slice the team pulls in for this sprint + the plan to deliver it.Increment — the sum of all completed items meeting the Definition of Done (DoD) — the shared checklist for "actually finished" (tested, reviewed, integrated).
Definition The ceremonies (time-boxed events)
Sprint Planning — pick what to build this sprint + how. (Why? Create a shared, achievable goal.) Daily Scrum / Standup — ~15 min: what I did, what I'll do, what blocks me. (Why? Surface blockers fast, re-plan daily.) Sprint itself — the time-box where work happens; scope can be renegotiated but the goal is fixed .Sprint Review — demo the increment to stakeholders, get feedback. (Why? Inspect the product .) Sprint Retrospective — team reflects on its own process and picks improvements. (Why? Inspect the process .)
Common mistake Review vs Retrospective confusionWhy it feels right: both happen at sprint end and both involve "looking back".
The fix: Review = product (did we build the right thing? show stakeholders). Retro = process (how did we work, internal team only). Mnemonic: Rev iew = v isible product; Ret ro = t eam.
Intuition WHY estimate in points, not hours?Humans are bad at absolute time ("this takes 6 hours") but decent at relative size ("this is twice that"). So teams assign story points (often Fibonacci-ish: 1,2,3,5,8) to capture relative effort/complexity.
Velocity = the number of story points a team completes per sprint, averaged over recent sprints. It is a measured , empirical number — never a target you push up.
Let p i p_i p i i i i n n n
Worked example Forecasting with velocityPast 3 sprints completed 18, 22, 20 points. Backlog = 240 points.
Step 1: v ˉ = ( 18 + 22 + 20 ) / 3 = 20 \bar v = (18+22+20)/3 = 20 v ˉ = ( 18 + 22 + 20 ) /3 = 20 Why average? smooths the noisy 22.Step 2: sprints = ⌈ 240 / 20 ⌉ = 12 =\lceil 240/20\rceil = 12 = ⌈ 240/20 ⌉ = 12 Why ceiling? 240/20 is exactly 12 here, so 12 sprints.If backlog were 250: ⌈ 250 / 20 ⌉ = ⌈ 12.5 ⌉ = 13 \lceil 250/20\rceil = \lceil 12.5\rceil = 13 ⌈ 250/20 ⌉ = ⌈ 12.5 ⌉ = 13 Why? the leftover 10 points still needs a whole sprint.
Common mistake "Push velocity up = more productive"Why it feels right: bigger number looks like more output, so managers set velocity targets.
The fix: velocity is relative to the team's own scale . Teams can inflate points ("point inflation") to hit targets without doing more. Velocity is a planning tool , not a performance KPI. Comparing two teams' velocities is meaningless.
A method that visualizes work as cards moving across a board (e.g. To Do → In Progress → Review → Done ) and enforces a Work-In-Progress (WIP) limit on columns. There are no fixed sprints, no roles, no time-boxes — work is pulled continuously when capacity frees up.
Intuition WHY limit WIP? (the traffic-jam idea)Start 10 things at once and everything is "90% done" forever — context-switching and waiting kill you. Limit WIP and you finish before you start new work , so things actually reach Done.
Common mistake "Kanban has no rules, it's just a board"Why it feels right: no sprints/roles makes it look casual.
The fix: Kanban's one strict rule is the WIP limit . Without it you just have a to-do list and Little's Law gives you ever-growing W W W
Scrum Kanban
Cadence
Fixed sprints (time-boxed)
Continuous flow
Limits work via
Sprint backlog (per sprint)
WIP limit (per column)
Roles
PO, SM, Devs
None prescribed
Change mid-cycle
Avoided during sprint
Anytime
Key metric
Velocity
Lead/cycle time (Little's Law)
Best when
Work is plannable in batches
Work arrives unpredictably (e.g. support)
"PO Steers, SM Smooths, Devs Solve" for roles.
"Plan, Stand, Sprint, Show, Reflect" = the 5 ceremonies in order (Planning, Standup, Sprint, reView/Show, Retro/Reflect).
Kanban: "Limit WIP, Watch the flow, Little's Law" — L = λ W L=\lambda W L = λW
Recall Feynman: explain to a 12-year-oldImagine baking cookies for a party but you don't know exactly what flavor people like.
Scrum way: every 2 weeks you bake one small batch, bring it to your friends, and ask "yummy?" Then you adjust next batch. The PO decides which flavor to try first, the Scrum Master makes sure the oven works and nobody distracts you, and you (the bakers) decide how to bake.
Kanban way: you have a board — "to mix", "to bake", "to taste". A rule says you can only have 2 trays in the oven at once. So you never start 10 trays and leave them half-baked. Fewer trays going at once = each cookie reaches the plate faster. That last bit is Little's Law: if 5 cookies finish per minute and 15 are in the kitchen, each waits 3 minutes.
What problem does Agile fundamentally fight against? Large batches of unverified work — the cost of being wrong grows the later you discover it.
List the 3 Scrum roles and what each owns. Product Owner (the what/why , orders backlog); Scrum Master (the process , removes blockers); Developers (the how it's built , self-organize).
Difference between Sprint Review and Sprint Retrospective? Review inspects the product (demo to stakeholders); Retrospective inspects the process (team-only reflection).
Name the 5 Scrum ceremonies in order. Sprint Planning, Daily Scrum (standup), the Sprint, Sprint Review, Sprint Retrospective.
What are the 3 Scrum artifacts? Product Backlog, Sprint Backlog, Increment (meeting the Definition of Done).
Define velocity and how to forecast with it. Average story points completed per sprint,
v ˉ = 1 n ∑ p i \bar v=\frac1n\sum p_i v ˉ = n 1 ∑ p i ; sprints needed
= ⌈ B / v ˉ ⌉ =\lceil B/\bar v\rceil = ⌈ B / v ˉ ⌉ for backlog
B B B .
Why must velocity NOT be used as a performance target? It's relative to a team's own scale; targeting it causes point inflation. It's a planning tool, not a KPI, and can't compare teams.
State Little's Law and its three variables. L = λ W L=\lambda W L = λW ;
L L L =WIP (items in system),
λ \lambda λ =throughput,
W W W =average lead/cycle time.
Why do WIP limits make delivery faster? By Little's Law
W = L / λ W=L/\lambda W = L / λ : lowering WIP
L L L at constant throughput
λ \lambda λ cuts lead time
W W W — fewer simultaneous items, less waiting.
Kanban vs Scrum cadence and key metric? Scrum = fixed sprints, metric velocity. Kanban = continuous flow with WIP limits, metric lead/cycle time.
The ideal burndown remaining-work formula? R ( d ) = W ( 1 − d / D ) R(d)=W(1-d/D) R ( d ) = W ( 1 − d / D ) — linear fall assuming constant rate
W / D W/D W / D per day.
What is the single strict rule of Kanban? The WIP limit per column — without it Little's Law makes lead time grow unboundedly.
Software Development Life Cycle (SDLC) — Agile is one SDLC model vs Waterfall.Waterfall Model — the big-batch approach Agile reacts against.Little's Law — queueing theory result reused in Kanban.Lean Manufacturing — Kanban's origin (Toyota production system).Continuous Integration & Delivery (CI-CD) — the engineering practice that makes shippable increments real.Project Estimation & Story Points — relative sizing behind velocity.
Big Batches of Unverified Work
Intuition Hinglish mein samjhoDekho, Agile ka basic idea simple hai: pehle saara software 2 saal plan karke ek baar deliver karna risky hai, kyunki tab tak customer ki requirement hi badal jaati hai. Iski jagah Agile bolta hai — chhote-chhote working pieces banao, customer ko dikhao, feedback lo, aur direction adjust karo. Jitni jaldi galti pakdoge, utna sasta. Yahi pura Agile ka asli "why" hai.
Scrum ek framework hai jahan kaam fixed-length sprints (1-4 hafte) mein hota hai. Teen roles yaad rakho: Product Owner decide karta hai kya banana hai aur priority kya hai; Scrum Master ek helper/coach hai jo blockers hatata hai (boss nahi hai, woh kaam assign nahi karta!); aur Developers khud decide karte hain kaise banana hai. Har sprint mein 5 ceremonies hoti hain — Planning, daily Standup, Sprint khud, Review (product stakeholders ko dikhana) aur Retrospective (team apne process pe sochti hai). Review aur Retro confuse mat karna: Rev iew = product v isible, Ret ro = t eam ka process.
Velocity matlab ek sprint mein team kitne story points complete karti hai (average). Isse forecast karte hain: backlog B B B v ˉ \bar v v ˉ
Kanban thoda alag hai — koi sprint nahi, koi roles nahi. Bas ek board hota hai (To Do → Doing → Done) aur har column pe WIP limit lagti hai, matlab ek time pe kitne kaam chalu rakh sakte ho. WHY limit? Kyunki agar 10 cheezein ek saath start kar do, sab "90% done" reh jaati hain aur kuch finish hi nahi hota. Little's Law (L = λ W L = \lambda W L = λW L L L W W W
