당신의 스크럼은 스크럼이 아니다. 스크럼 가이드는 13페이지. 당신의 프로세스는 300페이지.

Source: Dev.to

번역을 진행하려면 전체 텍스트를 제공해 주시겠어요? 텍스트를 주시면 요청하신 대로 한국어로 번역해 드리겠습니다.

Background

원본은 theendofcoding.com에 게시되었습니다.

Scrum Guide는 13페이지 분량입니다. user story와 epic이라는 용어는 한 번도 등장하지 않으며, velocity라는 단어도 전혀 나오지 않습니다. 2010년 이후로 story points는 언급되지 않았습니다. Planning poker, Fibonacci, “As a user, I want,” Given/When/Then, 2주 스프린트 등—이 모든 것이 Guide 안에 없습니다. 대부분의 엔지니어링 조직이 Scrum이라고 부르는 것은 20년 동안 책, 도구, 컨설턴트가 추가한 민간 레이어이며, Guide 위에 얹어진 것입니다. 스프린트 계획에서 팀이 싸우는 대부분의 내용은 실제 Scrum이 아니었습니다.

이는 Scrum에 대한 비판이 아닙니다. Scrum Guide 자체는 괜찮습니다. 이 글에서 열거한 부풀림(bloat)은 중대형 기업들이 책, 도구, 컨설턴트의 관행을 여기저기서 끌어와서, 10분이면 읽을 수 있던 것이 300페이지에 달하는 문서가 되도록 만든 결과입니다. 대부분은 좋은 의도로 추가된 것이지만, 한 번도 필수적이진 않았습니다.

이 부풀림이 AI 가속화 하에서 문제를 악화시킵니다. 실행이 병목이었을 때는 추가적인 세레모니와 Fibonacci 논쟁이 스프린트 하나를 차지했습니다. AI가 코드 작성 비용을 한 차례에 한 단계 낮추면, 같은 세레모니와 같은 논쟁이 이전에 그 안에 있던 전체 일주일 작업을 차지하게 됩니다. 인간‑키보드 속도에서는 감당할 수 있던 프로세스 오버헤드가 이제는 병목이 됩니다. AI가 실제로 가능하게 하는 속도로 배포하는 팀은 기업 Scrum을 원래 13페이지 문서에 가깝게 축소하고, 나머지는 15년 전 속도가 아니라 현재 작업 속도에 맞춘 워크플로우로 대체한 팀들입니다.

스크럼 가이드 (2020)

스크럼 가이드 — Ken Schwaber와 Jeff Sutherland가 작성하고 2020년 11월에 마지막으로 개정된 이 가이드는 놀라울 정도로 적은 내용을 규정합니다:

• 세 가지 역할 – 제품 소유자, 스크럼 마스터, 개발자.
• 다섯 가지 이벤트 – 스프린트 자체, 스프린트 계획, 데일리 스크럼, 스프린트 리뷰, 스프린트 회고.
• 세 가지 산출물 – 제품 백로그, 스프린트 백로그, 인크리먼트.
• 완료 정의.
• “한 달 이하”인 스프린트.

각각의 개정은 규정을 추가하기보다 제거했습니다. 아래 내용은 모두 관행적인 보완이며, 여기 가장 큰 10가지 항목과 각각에 대한 대응 방안을 제시합니다.

Source: …

Ten Common Folk Overlays

1. Scrum requires user stories (and epics)

The claim. Scrum teams track work as user stories. Larger groupings are epics. That’s the structure.

The Scrum Guide. Refers to “Product Backlog Items.” The terms user story and epic never appear in any version of the Guide.

The origin. Both come from Extreme Programming. Kent Beck’s Extreme Programming Explained (1999) used “story” for a unit of user‑facing work, with “epic” as the colloquial term for a story too large to deliver in one cycle. Mike Cohn formalized both in User Stories Applied (2004) and Agile Estimating and Planning (2005). Atlassian’s Jira then institutionalized the Epic → Story → Sub‑task hierarchy as a product feature, and a generation of tools followed Jira’s lead. None of which makes any of it Scrum.

Do this instead. The term doesn’t matter — different systems use different ones (issue, ticket, work item, task) and they all work fine. What matters is the underlying concept: a unit of work, ordered in a backlog. Hierarchy is useful — group related work together so progress on a larger initiative is visible — but two levels handle most needs: a grouping concept on top, a unit of work below. Two types — feature‑shaped work and pure‑technical work — is usually enough. Resist the temptation to configure ten work‑item types each with its own custom workflow. Simpler tools are faster, the team’s mental model stays lighter, and the simplification compounds with AI: agents reasoning about your backlog work better when there are fewer types and shapes to disambiguate.

2. Story points are a Scrum concept

The claim. Every “real” Scrum team estimates in story points.

The Scrum Guide. Mandates estimation, prescribes no method. The Guide has not mentioned story points since 2010.

The origin. Ron Jeffries coined story points as part of Extreme Programming in the late 1990s — initially to abstract “ideal days” into a unitless number that prevented managers from locking in rigid commitments. Mike Cohn popularized them in Agile Estimating and Planning (2005). In a 2019 blog post titled “Story Points Revisited,” Jeffries himself wrote:

“I like to say that I may have invented story points, and if I did, I’m sorry now.” — Ron Jeffries, 2019

He went on to call comparing teams on velocity “harmful.” The person credited with inventing the unit publicly disowned it.

Do this instead. Estimate in real‑time units. Effort in hours. Duration derived from real team capacity, accounting for vacations, support load, and the percentage of development time that actually exists in a working week. The unit business leadership needs to plan around is a delivery date — and story points were a translation layer between something developers could approximate and something the business could schedule. Every link in that translation introduces distortion. Skip the layer.

3. Planning poker is a Scrum ceremony

The claim. Real Scrum teams play planning poker to estimate together.

The Scrum Guide. Never mentions it. In any version.

The origin. James Grenning introduced planning poker in a 2002 paper titled Planning Poker or How to avoid analysis paralysis while release planning — written for Extreme Programming release planning, not Scrum. Mike Cohn later popularized it for Scrum teams in Agile Estimating and Planning (2005), which is also how it spread.

Do this instead. Asynchronous breakdown, AI‑first estimation. Modern AI tools can read a change description, propose a breakdown, and estimate both the AI execution portion and the human review‑and‑validation portion as separate components of each work unit.

Developers review those numbers the same way they review AI‑generated code — not from scratch, but with judgment applied to a draft. Combining the AI portion and the human portion in each unit of work is often more accurate than a developer guessing.

Source: …

g in isolation, because both pieces become quantifiable once the scope is explicit. Dev leads clarify requirements where the AI was uncertain.

The kickoff that replaces sprint planning is for alignment, not estimation: is the scope coherent, are the dependencies visible, is the duration realistic, are the risks understood. Planning poker made sense when estimation was hard and group calibration required a synchronous ritual. With AI carrying the first‑pass numbers, the calibration ceremony has shrunk to a confirmation conversation.

4. A proper sprint is two weeks

The claim. A proper sprint is two weeks. One week is too short, three weeks is too long.

The Scrum Guide. “One month or less.” That is the entire prescription. No specific duration.

The origin. The two‑week default crystallized in the early 2000s as a compromise between “weekly is too much overhead” and “monthly is too long for feedback.” Then Jira shipped two‑week sprints as a default template in the mid‑2000s, and a generation of teams inherited the cadence without questioning it.

Do this instead. Variable durations derived from effort and capacity. Each initiative gets its own duration window — calculated from estimated effort divided by available developer capacity, with a multiplier for meetings, reviews, and overhead. A small initiative might run a week. A platform migration might run six weeks. Forcing both into the same fixed two‑week container is what makes sprints feel arbitrary — because they are.

5. Velocity is a Scrum metric

The claim. You measure team performance with velocity. A healthy team has stable velocity.

The Scrum Guide. The word velocity appears zero times in any version of the Scrum Guide. It has never been a Scrum concept.

The origin. Velocity comes from Mike Cohn’s books and the broader Agile‑coaching ecosystem of the early 2000s. It became universal because dashboards needed something to chart and story‑point throughput was easy to count.

Do this instead. Effort‑based burndown tracked against a real‑time budget. Estimate effort in time units, log time as work progresses, watch the burndown deviate.

• Spike upward in remaining work? Scope was added — make the trade‑off visible.
• No movement? Something is blocked — surface it.
• Steady drift? Underestimate — recalibrate.

Burndown is variance detection, not performance scoring. It tells you when to have a conversation about reality, not when to congratulate or punish.

6. “As a user, I want…” is mandatory

The claim. Every story must follow the “As a [role], I want [feature], so that [benefit]” template. It is what makes a story a “user story.”

The Scrum Guide. Never mentions user stories or the template. The Guide refers to Product Backlog Items — no format prescribed.

The origin. The template was invented at Connextra Ltd., a London software company, in 2001 — originally called “role‑feature‑reason.” Mike Cohn popularized it in User Stories Applied (2004). The Agile Alliance’s own glossary, maintained by the organization that stewards the Agile Manifesto, describes the template this way:

“Training wheels… often outgrown once past the novice stage. Many novice teams fall into rote application… spending much effort and time on complying with user story templates is without much point.” — Agile Alliance glossary

The Agile Alliance is, in effect, telling you to stop using their own template once you know what you are doing.

Do this instead. Direct, scannable titles that read as actions.

• Add auth retry logic.
• Implement search filtering.
• Refactor API query boundaries.

The discipline the template was trying to instill — name the user, the capability, the reason — is still product thinking. You do not need a template to have that conversation. You need a team that asks those questions, and increasingly, AI assistance that translates intent into whatever str

Source: …

7. 피보나치 스케일이 더 정확하다

The claim. 1, 2, 3, 5, 8, 13으로 추정하는 것이 선형 스케일보다 더 정확하다는 주장. 이는 규모가 커질수록 불확실성이 커진다는 점을 인정한다.

The Scrum Guide. 피보나치를 언급하지 않는다.

The origin. Mike Cohn의 Agile Estimating and Planning (2005)에서 유래. 이론적으로는 타당한 주장—8과 9를 의미 있게 구분하기 어렵기 때문에 스케일 간격이 커져야 한다는 논리. 실제로는 간격이 팀에게 더 많은 숫자를 두고 논쟁하게 만든다.

Do this instead. 스케일 자체가 필요하지 않으며, 대부분의 팀은 스케일을 사용하지 않아도 된다. 실제 시간—시간, 일, 작업에 맞는 단위—으로 추정하라. 가장 낙관적인 경우와 최악의 경우 사이의 중간점을 목표로 한다: 너무 공격적이라 대부분의 추정이 실패하지도, 너무 완충해서 팀이 지속적으로 자체 역량보다 못 미치지 않도록 한다.

아이디어가 실행에 가까워질수록 정밀도가 향상된다—초기 단계 아이디어는 대략적인 추정, 작업이 계획 단계에 들어가면 정제한다. 추정과 현실 사이의 층이 적을수록 리더십, 개발자, 계획을 수행하는 사람 모두에게 더 명확해진다.

툴이 숫자 스케일을 강제한다면(몇몇 시스템이 그렇다), 팀이 눈으로 바로 추측할 수 있을 정도로 매핑을 단순하게 유지하라: 모든 숫자는 일(day)이라는 가장 안전한 가정. 반패턴은 조직 전체에서 사람마다 의미가 다른 추상적인, 팀‑특화 포인트이다.

8. 스프린트 회고는 1시간, 3컬럼 의식이어야 한다

The claim. 모든 스프린트는 1시간 회고로 끝난다. 3개의 컬럼: 잘한 점, 안 된 점, 다음에 시도할 것.

The Scrum Guide. 스프린트 회고는 다섯 가지 이벤트 중 하나로 존재한다. 형식은 명시되지 않았다. 빈도는 스프린트 주기에 따라 결정되며, 스프린트 주기도 팀이 정한다.

The origin. 3컬럼과 표준 질문 형식은 가이드가 아니라 애자일 코칭 실무에서 온 것이다. 시작 구조로서는 합리적이다. 그러나 팀이 수년간 자동조종으로 같은 오래된 결과만 반복하고, 의무적으로 참석하는 회의가 되면서 문제가 발생했다.

Do this instead. 검사‑적응(inspect‑and‑adapt)이 원칙이며, 반복 회의 자체가 원칙은 아니다. 회고가 의미 있는 변화를 만든다면 계속한다. 회고가 아무도 행동하지 않는 오래된 리스트만 만든다면 형식을 바꾸고, 주기를 조정하거나, 서면 반성으로 대체하거나, 팀에 실제 논의할 내용이 있을 때만 진행한다. 아무도 믿지 않는 의식은 신뢰를 부식시킨다. 가이드는 형식을 다양화할 수 있는 허가를 주고 있는데, 대부분의 팀은 그 허가를 한 번도 사용하지 않았다.

9. 백로그 정제는 금요일에 2시간 예약 회의이다

The claim. 금요일 오후는 백로그 정제를 위한 시간이다. 전체 팀이 참석한다. 2시간 동안 다가오는 스토리를 검토한다.

The Scrum Guide. 정제는 필요에 따라 스프린트 내내 진행되는 지속적인 활동으로 설명된다. 별도의 의식이나 예약된 회의, 정해진 주기는 제시되지 않는다.

The origin. 2시간 정제 회의는 모든 작업이 동기식으로 진행되어야 하고, 작업을 분해하려면 집단적인 해석이 필요했던 기업 환경에서 최적화된 형태다.

Do this instead. 적시 분해(just‑in‑time breakdown). 개발 리드가 스토리를 실행 직전에 정제한다. AI가 분해를 도와 모호성을 드러내고 수용 기준을 초안한다. 목표 지향적인 대화가 전체 팀 회의를 대체한다. 우선순위가 바뀔 수 있는 스토리를 미리 많이 정제하는 것은 낭비다.

가장 간단한 테스트: 정제 회의가 없었다면 알 수 있었을지 여부를 물어보라. 그렇다면 그것은 과도한 부하이다.

10. 데일리 스크럼은 상태 업데이트 라운드‑로빈이다

The claim. 서서 진행한다. 세 가지 질문: 어제 무엇을 했는가, 오늘 무엇을 할 것인가, 무엇이 방해가 되는가. 팀 전체를 돌아가며 답한다. 15분.

The Scrum Guide. … (이하 내용은 원문에 이어서 번역하면 됩니다.)

15분짜리 이벤트를 지정하여 개발자들이 스프린트 목표에 대한 진행 상황을 점검하고 스프린트 백로그를 조정합니다. 형식은 정해져 있지 않으며, 청중은 이해관계자가 아니라 개발자입니다. 가이드에는 세 질문 형식이 포함되어 있지 않습니다.

기원. 세 질문 형식은 XP 시대의 실천과 Mike Cohn 시대의 코칭에서 유래되었습니다. 2003년에는 도구가 부족해 개발자들이 구두로 조정할 필요가 있었기에 의미가 있었습니다. 오늘날에는 “어제 무엇을 했는가”에 대한 대부분이 풀 리퀘스트, 티켓 히스토리, 슬랙 스레드에 표시됩니다. 이를 큰 소리로 말하는 것은 조정이 아니라 보고가 되었습니다.

대신 이렇게 하세요. 데일리 스크럼의 실제 가치는 기계적인 업데이트가 아니라, 서로 다른 컨텍스트를 가진 개발자들이 하루에 한 번 같은 방에 모였을 때 발생하는 비예정적인 교차‑오염입니다. 누군가가 에스컬레이션을 언급하면, 다른 사람이 “잠깐, 그게 모듈 X에서 내가 보는 것과 관련이 있는 것 같아.”라고 말합니다. 부수적인 논의는 나중에 일정에 잡히게 됩니다. 아무도 문제라고 인식하지 못했던 새로운 이슈가 누군가의 경험을 통해 다른 사람의 업데이트와 연결되면서 드러납니다.

이 회의가 스스로 비용을 회수하는 순간은 특히 예기치 않은 작업—에스컬레이션, 지원 부하, 교차 관심사—에서 올바른 대화 상대가 누군지 명확하지 않을 때, 누군가가 문제를 큰 소리로 설명함으로써 알게 되는 경우입니다.

따라서 스탠드‑업을 유지하세요. 빠르게 진행하세요. 사람들이 무엇을 작업하고 있는지에 대한 가벼운 가시성은 상태 보고가 아니라 주변 인식이라는 실질적인 가치가 됩니다. 잡담이 부수적인 논의로 이어지도록 장려하세요.