Scrum 및 SAFe 맥락에서 Cumulative Flow 적용 사례

이 글에서는 우리가 실제로 Scrum 과정에서 SAFe 프레임워크로 작업하면서 Cumulative Flow Chart를 어떻게 적용하는지 이야기하려 합니다. SAFe

우선 이 글 에 대한 링크로 시작하겠습니다. 제 생각에 이 글은 표준 형태에서의 그 용도를 잘 설명하고 있으니, 제 글을 읽기 전에 살펴보시길 권합니다. 아래에서는 우리가 이를 Scrum 프로세스에 맞게 어떻게 조정했는지(원래는 Kanban에서 사용됩니다) 그리고 스프린트 작업에서 어떤 문제들을 해결하는 데 도움이 되는지 설명하겠습니다.

앞서 Burn Down Charts에 관한 글 에서 이미 말했듯이, 거기서는 새로운 작업의 등장과 기존 작업의 소진을 볼 수 있습니다. Burn Down Chart의 문제는 Cumulative Flow Chart와 달리 사용자 스토리의 상태별 이동을 볼 수 없다는 점입니다. 반면 Cumulative Flow Chart에서 상태별 이동을 관찰하기 시작하면 일별 변화를 볼 수 있게 되고(Burn Down Chart는 며칠 동안 변하지 않을 수 있으며 일부 맥락에서는 이것이 전혀 정상일 수 있습니다) 더 미세한 문제들을 발견할 수 있습니다.

다음은 이것이 역동적으로 어떻게 보일 수 있는지입니다(이미지는 실제 데이터로 작성된 다이어그램입니다).

이 예시에서 우리는 다음을 볼 수 있습니다

• 스프린트 첫 7일 동안 테스트에 있는 작업량이 매우 적고 변하지 않습니다
• DOR(여기서는 초안)에서 작업으로 사용자 스토리가 비교적 균등하게 이동합니다 - 이는 좋습니다.
• Burn Down에서와 마찬가지로, 추세에 따르면 사용자 스토리가 스프린트가 끝날 때까지 완료되지 않을 것임을 알 수 있습니다

이 세 가지 관찰을 종합하면 다음과 같은 결론에 이릅니다. 여기서는 분명히 더 이른 단계(대략 스프린트 둘째-셋째 날)에 Scrum Master가 너무 작고 오랫동안 변하지 않는 "테스트" 계층에 주목했어야 했습니다(원인이 무엇인지 확인해야 함). 테스트 준비가 된 작업량을 어떤 상황 때문에 테스트할 수 없다고 가정할 수도 있지만, 그렇다면 이는 테스터들이 유휴 상태라는 뜻이므로 최소한 가장 가까운 스탠드업에서 그들의 말을 더 주의 깊게 들어야 합니다.

적용 사례에 관해 말하자면, 예를 들어 저는 매일 팀 채팅에 스탠드업 전에 모든 팀원을 언급하며 모든 지표를 게시합니다.

전반적으로, 지표는 여전히 올바르게 해석해야 한다는 점을 잊지 말아야 합니다. 실제로 시스템적 문제가 있다면 그것을 볼 수 있어야 하고, 여러분의 맥락에서는 오히려 긍정적인 신호일 수 있는 것을 문제로 받아들이지 않아야 합니다