business-impact scoring이 포함된 sprint retrospective 만들기(Build a sprint retrospective with business-impact scoring)

학습이 복리처럼 쌓이는 retrospective

대부분의 retrospective는 늘 같은 세 가지 action item을 순환합니다. 더 잘 커뮤니케이션하자, 테스트를 더 쓰자, 더 잘 계획하자 같은 것입니다. Atlassian의 retrospective guide는 반복되는 추상 action item이 문제의 증상이라고 지적합니다. 원인은 비즈니스 결과와 분리된 채 팀 dynamics만 이야기하는 retrospective입니다. The Pragmatic Engineer의 engineering productivity 글은 강한 팀일수록 retro 학습을 meeting quality가 아니라 shipped outcome과 explicit impact scoring에 연결한다고 말합니다.

이 프롬프트의 작동 방식

이 프롬프트는 discussion 전에 impact table부터 보게 하여, 어떤 shipped work가 실제로 metric을 움직였는지 먼저 드러내고, outcome을 분류해 win과 wasted effort를 따로 이름 붙이게 하며, action item이 관찰된 specific failure mode에 매핑되도록 강제합니다. 각 action item에 붙는 "이게 먹혔음을 보여 줄 trigger"가 바로 강제 장치입니다. Generic action item은 사라지고, trigger가 있는 action item만 검증됩니다.

언제 사용할까

• Retrospective마다 같은 세 action item이 반복될 때
• 팀이 어떤 shipped work가 중요했는지 설명하지 못할 때
• 새 PM이나 EM이 retro discipline을 리셋하고 싶을 때
• Wasted effort가 높은데 팀이 서로 product/engineering만 탓할 때
• 리더십이 실패에서 배운 증거를 요구할 때

흔한 함정

• 팀 감정부터 시작하는 것. Feelings-first 회고는 root cause까지 못 갑니다. Impact table부터 보세요.
• Generic action item. "커뮤니케이션을 더 잘하자"는 actionable하지 않습니다. 다음에 어떤 signal을 보면 어떻게 바꿀지 적어야 합니다.
• 다음 retro에서 action item을 검토하지 않는 것. Review date 없는 action item은 곧 사라집니다. 반드시 점검 일정을 잡으세요.

참고 자료

• Sprint Retrospectives — Atlassian
• The Pragmatic Engineer Newsletter — Gergely Orosz
• Embracing Agile — Harvard Business Review
• The Power of Small Wins — Harvard Business Review