SAFe와 Scrum 맥락에서 Burn Down Chart 적용 사례

이 글에서는 우리가 SAFe 방법론에 따라 작업하는 과정에서 번 다운 차트(Burn Down Chart)를 어떻게 실무에 적용하고 있는지 이야기할 계획입니다

가장 흥미로운 것부터 시작하는 게 좋겠습니다. 즉, 이 차트를 SAFe에서 사용하는 것이 SCRUM에서 사용하는 것과 어떤 특별한 차이도 있어서는 안 된다는 점입니다. 아니면 있어야 할까요?

우리 SAFe는 RTE라는 역할이 있다는 점에서 SCRUM과 다릅니다. SCRUM에는 그런 역할이 없죠. Burn Down Chart는 스프린트 내 작업량을 추적하는 도구이며, 무엇보다도 SCRUM 팀을 위한 것이지 외부의 누군가를 위한 것이 아니지 않습니까?

그러므로 그럼에도 불구하고, 여전히 SAFe 프레임워크 안에 있으면서 우리가 Burn Down Chart를 어떻게 사용하는지로 넘어가겠습니다.

저는 Scrum Master 역할을 맡고 있으며, 이 차트를 매일 전체 Dev Team에게 보여주려고 노력합니다. 제가 사용하는 수단은 팀 채팅에서 "@"를 통해 전체 팀을 멘션하고 차트의 현재 상태 스크린샷을 올리는 것입니다. 전체 팀 멘션은 상당히 섬세한 도구이며 가능한 한 드물게 사용하는 것이 중요합니다(결국 우리 스크럼 마스터는 팀이 편안하게, 가능한 한 최소한의 집중 분산으로 일하도록 도와야 하지 않습니까?).

결과적으로 팀은 매일 스프린트의 현재 상태를 보고 다음 사건들을 추적할 수 있습니다

• 계획되지 않은 작업의 등장
• 미완료 상태에서 오래 머무는 작업
• 과도한 리스크 반영
• 작업이 올바른 속도로 진행되고 있는지에 대한 이해

이제 각 사건을 자세히 설명하고 제 실무에서의 예를 들려고 합니다.

계획되지 않은 작업의 등장

이 차트에서는 새로운 작업이 어떻게 등장하는지(2주 스프린트의 두 번째 화요일) 매우 잘 드러납니다.

실무 사례: "애자일 원칙을 공유하는 스크럼 팀의 일원인 개발자가 Product와 직접 훌륭하게 소통합니다. Product가 그에게 이건 빨리 넣어야 한다고, 당신도 알다시피 여기는 빠르고 리스크도 최소라고 말합니다.

개발자는 훌륭하고 애자일과 비즈니스 가치 전달의 중요성에 대해 모두 알고 있으며, 백로그에서 스토리를 보드에 던져 넣고, 팀이 이를 6 sp로 추정했습니다.

팀의 나머지(개발자와 Product를 제외한)는 아침 차트 업데이트에서 이를 알아차립니다. 스탠드업에서 팀은 이 상황을 어떻게 처리할지 결정합니다. 아마도 스토리는 스프린트에서 제외되고, 팀은 Product와 개발자에게 그렇게 해서는 안 된다는 것을 알리며, 필요하다면 Product는 이 스토리를 다음 스프린트에 넣을 수 있습니다.

물론 이상적으로는 팀이 차트 없이도 스탠드업에서 새로운 작업의 등장을 알아차려야 합니다. 하지만 차트는 팀 전체에 중요한 이 변화를 놓치지 않을 리스크를 최소화하는 좋은 지표입니다.

여기서 중요한 것은 팀의 수준에 따라 시나리오가 다르게 전개될 수 있었다는 점입니다. 뛰어난 팀에서는 제품 책임자가 그렇게 하지 않았을 것이고, 설령 했다 하더라도 "이건 빨리 넣을 수 있다"는 이유가 아니라 "지금 넣으면 다음 달 우리 수익을 20% 늘릴 수 있을 확률을 55%로 평가한다"거나 다른 측정 가능한 지표로 근거를 댔을 것입니다.

미완료 상태에서 오래 머무는 작업

여기서 우리는 매우 오랫동안 작업이 부분적으로도 완료되지 않는 것을 볼 수 있습니다. 이는 다양한 문제를 시사할 수 있으며, 그중 몇 가지를 나열하겠습니다

• 잘못된 작업 분해

  매우 자주 초보 팀들은 분해가 불가능하다고 말합니다. 그들은 모든 것이 마지막 날에 불타버리고, 작업이 병렬화되지 않는 등입니다. 물론 이에 대해 스크럼 마스터가 작업하고 팀에게 분해의 가치를 설명해야 합니다.

• 최적이 아닌 DOD 정의

  DOD(Definition of Done)는 스프린트에서 User Story의 완료 기준에 대한 설명입니다. 때로는 아예 없거나 매우 추상적으로 기술되어 있습니다. 이는 충분히 문제가 될 수 있으며, 당연히 스크럼 마스터가 해결을 도와야 합니다

과도한 리스크 반영

이 경우 팀이 리스크를 과도하게 반영한 상황을 볼 수 있습니다.

아마도 어떤 스토리가 과대평가되었을 수 있습니다. 어쩌면 이는 더 시스템적인 문제이며 스프린트 계획 시 작업량을 늘려야 할 수도 있습니다. 어쨌든 이 상황은 올바르지 않습니다. 비즈니스는 바로 스프린트의 작업이, 바로 스프린트가 끝날 때쯤 구현될 것이라고 계획했기 때문입니다. 의존성이 어떻게 계획되었는지에 따라, 여기서는 아마도 기대치를 조정하기 위한 회의를 진행해야 할 것입니다.

제 경험상 추정 시 논의했던 것보다 더 빠른 해결책이 발견된 경우가 있었습니다. 팀 전체가 스프린트가 끝나기 전에 어떤 스토리를 마감할 수 있을지 논의했고, 회고에서 그루밍 시 코드를 살펴보도록 노력하자고 합의했습니다. 코드를 잠깐 들여다보기만 하면 해결책이 훨씬 더 단순하다는 것을 알 수 있었습니다.

이해 - 작업이 올바른 속도로 진행되고 있는가

여기서 저는 Burn Down Chart의 그래픽적으로 실패한 표시 방식에 주목하고 싶습니다

이미지 상단에는 아래에서 설명할 두 가지 이유로 그다지 성공적이지 않은 그래픽 구현의 예가 나와 있습니다.

• 새로운 SP가 스프린트에 추가된 것이 눈에 띄지 않음

  여기 상단 다이어그램에서는 계획되지 않은 작업이 추가된 것이 거의 눈에 띄지 않습니다. 하단에서는 더 명확합니다.

• 상대적 잔여 작업량이 올바르게 표시되지 않음

  상단 다이어그램에 따르면 아직 3일을 더 작업해야 합니다. 실제로는 2일이며, 휴일에는 누군가 휴식을 계획하고 있을 수 있습니다.

물론 누군가에게는 이런 사소한 것들이 중요하지 않게 보일 수 있습니다. 하지만 각 팀원은 이 다이어그램을 곁눈질로만 볼 것이며, 이 다이어그램은 최대한의 유용한 정보를 전달해야 한다는 점을 이해해야 합니다.