레트로스펙티브 액션 아이템은 어디에 속하나요? (아마도 Jira에는 아닐 것 같습니다)

Source: Dev.to

당신의 팀은 훌륭한 회고를 진행합니다. 사람들은 솔직합니다. 세네 개 정도의 진정으로 좋은 액션 아이템이 보드에 올라갑니다. 누군가가 “I’ll put these in Jira.” 라고 말합니다. 모두가 고개를 끄덕입니다. 두 주가 지나 다음 회고에서 누군가가 같은 문제를 제기합니다.

그 순간이 수천 개 팀에 걸쳐 곱해질 때, 2023 Scrum Alliance survey에서 **35 %**의 팀만이 회고 액션 아이템을 지속적으로 완료한다는 결과가 나온 이유가 됩니다. 나머지 **65 %**는 대화를 진행하고 통찰을 생성하지만, 약 일주일 내에 그 통찰을 잃어버립니다.

두 가지 일반적인 진영

두 진영 모두 같은 이유로 실패합니다: 저장 위치가 작업의 흐름과 형태에 맞지 않기 때문.

• Jira는 보드에서 흐르는 우선순위가 매겨진 고객 대면 작업을 위해 설계되었습니다. 회고 아이템은 보통 그렇지 않습니다.
• 공유 문서는 아무것도 추적하지 않으며, 가시성이나 알림 메커니즘이 없습니다.

왜 Jira에 액션 아이템을 넣는 것이 책임감 있어 보이지만 결국 실패하는가

1. 이해관계자 없음 – Jira 티켓은 고객이나 PM이 무언가를 배포하기를 원하기 때문에 존재한다. 회고 아이템은 팀이 스스로를 고치고 싶어서 존재한다. 외부 압력이 없으면, 그것들은 사라진다.
2. 그루밍이 파괴한다 – 백로그는 영향, 긴급성, 고객 고통을 기준으로 우선순위가 매겨진다. “5항목 PR 체크리스트 추가”는 모든 고객‑대면 티켓에 밀려 영원히 뒤처진다.
3. 다음 회고에서는 보이지 않는다 – 팀이 다시 브레인스토밍할 때, 아무도 Jira를 열어 아직 열려 있는 것이 무엇인지 확인하지 않는다. 정보는 기술적으로 존재하지만, 흐름이 그것을 다시 방 안으로 가져오지 않는다.
4. 프로세스 개선은 범위를 축소하지 않는다 – “블로커에 대해 더 잘 소통하기” 혹은 “계획 전에 정제하기”는 티켓이 아니다. 이를 스토리‑포인트와 수용 기준 형태로 강제하면 왜곡되고 실행하기 더 어려워진다, 쉬워지는 것이 아니다.

작업 항목이 트래커에 포함되어야 할 때

테스트: 해당 작업이 자체적인 가치만으로 스프린트 계획 회의에서 일반 티켓으로 살아남을 수 있는가?

정리 규칙: 작업 항목이 스프린트 계획에서 일반 티켓으로 살아남을 수 있다면, 트래커에 푸시한다(원클릭 내보내기, 레트로 항목에 링크 반환, 그리고 진행).

거의 모든 다른 항목은 회고 도구에 포함됩니다

• “금요일에 리파인먼트 일정을 잡는 것을 중단하세요.”
• “각 회고 끝에 5분간의 Kudos 라운드를 진행하세요.”
• “다음 두 사이클 동안 실험적으로 4일 스프린트를 시도해 보세요.”
• “릴리즈 매니저가 승인하지 않는 한 금요일에 머지를 중단하세요.”

이것들은 약속과 의식입니다. 중요하지만 스프린트 보드에 맞는 완료 정의가 부족합니다. 기능 작업과 우선순위 경쟁 없이 매주 다시 검토할 수 있는 장소가 필요합니다 – 당신의 회고 도구.

Source:

엔지니어링 트래커가 잘 못하는 네 가지

1. 연속성 – 다음 회고가 열리면, 이전 스프린트의 미해결 액션 아이템이 바로 거기에 있어야 합니다. 새로운 아이템을 브레인스토밍하기 전에 이를 보는 것이 다른 어떤 개입보다도 실행을 촉진합니다.
2. 맥락 – 액션 아이템은 그것을 만든 회고 항목 옆에 위치합니다. 클릭하면 원래 토론, 투표, 그리고 이유를 확인할 수 있습니다. Jira 티켓은 몇 주가 지나면 해독하기 어려운 한 줄짜리 제목이 됩니다.
3. 리듬 – 회고 액션 아이템은 주간 심장박동이 필요합니다. 스프린트 보드의 티켓은 매일 스탠드업에서 주목받지 않으면 묻혀 버립니다.
4. 패턴 감지 – 같은 문제가 6주 동안 세 번의 회고에 걸쳐 나타난다면, 이는 일회성 불만과는 다른 문제입니다. Jira는 아이템들이 서로 연관돼 있다는 사실을 알지 못하기 때문에 이를 드러내지 못합니다.

처음으로 “이 팀이 6주 동안 세 번의 회고에서 CI 불안정을 제기했으며, 그 회고 중 하나의 액션 아이템만 완료되었다”는 도구의 경고를 보았을 때, 나는 우리가 같은 문제를 얼마나 자주 미루고 있었는지 과소평가하고 있었다는 것을 깨달았습니다. 불편했지만, 1년 동안 팀에 대해 얻은 가장 유용한 단일 데이터 포인트였습니다.

실용적인 워크플로 (Kollabe 기반)

1. 액션 아이템은 해당 레트로와 함께 존재합니다.
   각 아이템은 담당자, 마감일, 상태를 가집니다.
   새로운 레트로를 시작하기 전에 다음 레트로에 표시됩니다.

2. 월요일 아침 이메일 알림 – 열려 있는 액션 아이템이 있는 사람에게는 아직 열려 있는 항목을 요약한 단일 이메일이 전송됩니다. 점심시간에 스크롤되는 슬랙 알림이 아니라, 주 초에 한 사람에게 직접 보내는 이메일입니다.

3. 주간 인사이트 보고서 (유료 플랜) – 매주 월요일 팀은 다음을 포함한 보고서를 받습니다:

   • 완료율 (이름별로 가장 오래된 미완료 항목)
   • 반복되는 테마 – 여러 레트로에 걸쳐 표시된 항목
   • 팀 헬스 스코어 – 액션 아이템 메트릭을 포함

TL;DR

• Jira는 실제로 구현 가능한 작업이며 스프린트 계획에서도 살아남을 수 있는 레트로 아이템에만 사용하세요.
• 그 외 모든 것—프로세스 개선, 의식, 실험—은 레트로 도구에 두어 주간 가시성, 컨텍스트, 패턴 탐지를 확보하세요.

이렇게 하면 열심히 만든 인사이트가 사라지는 일을 방지할 수 있습니다.

액션 아이템 관리

점수는 거의 항상 팀이 액션 아이템을 닫는 것보다 더 빠르게 생성하기 때문에 떨어집니다. 이는 프로세스 불만이 아니라 리더십 신호입니다.

실제 배포 가능한 작업인 액션 아이템의 경우, 한 번 클릭으로 Jira, GitHub Projects, 또는 Linear에 푸시하고, 레트로 아이템으로 돌아가는 링크를 추가합니다. 중요한 것은 특정 도구가 아니라 루프입니다:

1. 액션 아이템 →
2. 소유자 →
3. 주간 알림 →
4. 다음 레트로에서 미해결 항목 표시 →
5. AI가 동일한 주제가 반복될 때 감지

Jira‑only 접근 방식이 괜찮은 경우

• 매우 작은 팀 (엔지니어 3‑5명)
• 전담 PM 없음
• 강력한 자율 문화

이러한 팀은 회고 액션 아이템을 별도로 보관할 필요가 없습니다. 움직이는 요소가 너무 적어 아이템이 사라지지 않기 때문이며, 전체 팀이 그 목록을 머릿속에 가지고 있습니다.

그렇다면 이 글의 나머지는 적용되지 않습니다.

팀 규모가 7명을 넘어가거나 PM 및 이해관계자 층을 추가하면 Jira‑only 패턴이 깨지기 시작합니다. 보통 한 분기 안에 느낄 수 있는데, 같은 불만이 연속 3번의 회고에 나타나면서 모두가 “우리가 작업 중이다”라고 주장합니다.

Decision Question: Action Item는 어디에 두어야 할까?

팀이 액션 아이템에 동의하면, 그 위치를 결정하기 전에 한 가지 질문을 하세요:

우리가 이걸 하지 않으면, 누가 실망할까?

• 한 가지 질문, 토론 없이 약 **90 %**의 액션 아이템을 올바르게 라우팅합니다.
• 나머지 **10 %**는 경계선에 해당하며, ≈30 초 정도 논쟁하게 됩니다. 이는 회고에서 어떤 주제든 논쟁하기에 적당한 시간입니다.

주요 요점

• 레트로는 진행하기는 저렴하지만 무시하면 비용이 많이 듭니다.

• 대화 형식 선택보다 액션 아이템이 나중에 어디에 배치되는지가 더 중요합니다.

• 액션 아이템에 다음과 같은 “집”이 없으면:

  1. 담당자를 살짝 자극하고,
  2. 스프린트 간에 지속되며,
  3. 같은 문제가 반복될 때 패턴을 드러내는

  회의 비용만 지불하고 배당금을 얻지 못하는 것입니다.

도구 및 워크플로

• 즉시 사용 가능한 살짝 자극 및 패턴 감지를 원한다면, Kollabe의 레트로스펙티브 도구가 무료 플랜에서 이를 처리하고, 프리미엄에서는 주간 인사이트 보고서를 제공합니다.
• 아니면 워크플로를 그대로 가져와 현재 사용 중인 도구에 적용하세요.
• “누가 실망했는가” 규칙은 무료이며, 질문만 하면 됩니다.