보드를 하나만 쓰면 안 되나

보드는 하나여도 됩니다. 오픈 범위 표는 따로 잠급니다. 잠근 표 없는 보드 하나가 한 목록입니다.

발주가 카드를 직접 올리면 빠른 거 아닌가

속도는 그날만 납니다. 번호 없는 이동은 기성 증빙이 없고, 검수 때 원래 범위와 어긋납니다.

스토리 점수를 기성률로 써도 되나

점수는 반복 완료입니다. 기성은 계약 산출물 묶음과 오픈 범위 표의 비율입니다.

안정화 중에 백로그를 계속 돌리면

오픈 4주 전에 이관 후 목록으로 분리하세요. 새 화면이 안정화 상단이면 구축 연장입니다.

제품 백로그 | SI 오픈 범위와 한 목록이면 안 되는 이유

오픈 범위 120본과 제품 백로그를 한 목록에 두면, 운영 개선 항목이 기성 칸을 밀어 오픈 범위가 매주 늘어납니다. 애자일 보드를 발주와 같이 보는 현장이 많습니다. 보이는 목록이 하나면 소통이 쉽다고 느끼기 때문이죠. 하지만 한 목록은 우선순위 손과 기성 손을 같은 칸에 앉힙니다. 같은 칸에 앉은 손은 검수 조서와 보드를 서로 다른 범위로 만듭니다. 이번 포스팅에서는 오픈 범위와 백로그를 두 목록으로 가르고 발주 손과 이관 칸을 맞추는 법을 자세히 다뤄보도록 하겠습니다. 스프린트 계획에 오픈 화면이 섞이기 시작하셨다면 목록을 둘로 쪼개 보세요.

목록	잠그는 것	움직이는 손	기성과의 관계
오픈 범위	계약 화면과 기능 ID	CCB, 월 1회 이하	기성 대상과 1:1
제품 백로그	이관 후에도 남는 순서	제품 우선순위, 주 1회	이번 사업 기성 밖
스프린트 백로그	이번 반복에 넣은 카드	팀, 반복 시작일	오픈 범위 카드만 기성 연결
발주 손	보기와 요청 글	옮기기 권한 없음	번호 없는 삭제는 증빙 아님
이관 후 목록	오픈 4주 전 분리	운영 개선 일정	안정화 백로그에 안 올림

한 목록을 세 손으로 쪼개야 하는 이유

오픈 범위와 제품 백로그를 한 목록에 두면 왜 안 되나?

오픈 범위는 계약 기준선입니다. 제품 백로그는 그 다음에도 남는 순서 목록입니다. 한 시트에 두면 운영 개선이 이번 스프린트 상단으로 올라와 오픈 화면을 밑으로 밀어냅니다.

보드에 카드가 80장이면 발주는 80장이 모두 오픈 대상처럼 읽습니다. 읽히는 순간 우선순위 회의는 무엇을 뺄지가 아니라 무엇을 더 위에 둘지가 됩니다.

위에 올라간 개선이 기성 대상이 되면, 원래 120본 중 밑줄 화면은 안정화로 밀리죠. 밀린 화면은 오픈 범위에서 사라진 것이 아닙니다.

검수 조서에는 아직 남아 있습니다. 애자일 반복을 쓰더라도 오픈 범위 목록은 잠근 표로 따로 두세요.

잠근 표의 변경은 백로그 드래그가 아니라 변경 번호입니다. 드래그로 오픈 대상을 바꾸면 기준선이 매일 바뀝니다.

매일 바뀌는 기준선은 기준이 아닙니다.

우선순위는 누가 어떤 손으로 옮기나?

오픈 범위의 순서는 발주 책임자와 CCB입니다. 제품 백로그의 순서는 제품 쪽 우선순위 손입니다. 스프린트 백로그의 순서는 팀이 이번 반복에 넣기로 한 손입니다. 세 손을 한 보드에서 동시에 쓰지 마세요.

한 보드에서 현업 팀장이 카드를 위로 올리면, 그 손은 세 목록을 한 번에 만진 것입니다. 만진 결과는 다음 날 개발 칸이 바뀌는 일로 나타납니다.

나타나는 속도가 빨라 보여도, 기성 대상과 오픈 대상이 같이 움직입니다. 같이 움직이면 나중에 어느 손이 옮겼는지 재구성이 안 됩니다.

재구성이 안 되면 분쟁 때 보드 히스토리 캡처만 남죠. 손을 가르는 최소 규칙은 이렇습니다.

오픈 범위는 월 1회 이상 안 움직이고, 제품 백로그는 주 1회 정렬하며, 스프린트 백로그는 반복 시작 날에만 확정합니다. 반복 중간에 올린 카드는 다음 정렬 후보입니다.

후보를 당일 개발에 넣지 마세요.

발주 손이 백로그를 직접 고치면 생기는 일은?

발주가 보드 관리자 권한으로 카드를 지우거나 올리면, 변경 이력이 도구 로그에만 남고 회의록에는 없습니다. 그 로그는 기성 증빙이 되기 어렵습니다.

보기 권한과 옮기기 권한을 가르세요. 발주가 보드를 보는 것은 투명입니다.

옮기는 것은 변경입니다. 변경이면 변경관리 번호와 영향 범위가 먼저입니다.

번호 없이 카드가 사라지면 팀은 완료로 착각하거나, 반대로 몰래 삭제된 범위로 착각합니다. 착각이 이틀만 가도 스프린트 리뷰 대상이 어긋납니다.

어긋난 리뷰는 신뢰 문제가 아니라 목록 문제죠. 발주 손은 요청 칸에만 글을 남기고, 옮기는 손은 수행 쪽 한 명으로 고정합니다.

고정한 이름이 주간보고에 있어야 다음 주에도 같은 규칙이 돕니다. 이름이 없으면 가장 급한 사람이 관리자가 됩니다.

기성 산정은 백로그 완료와 어떻게 다르나?

백로그 완료는 팀의 이번 반복 완료입니다. 기성은 계약 단계의 산출물과 범위가 조서에 남는 비율입니다. 스토리 점수 합을 기성률에 그대로 넣지 마세요.

스토리 30점을 끝냈다고 단계 기성 30%가 되지 않습니다. 기성 단계는 보통 설계, 구현, 시험, 검수처럼 계약 산출물 묶음입니다.

묶음 안에 오픈 범위 화면이 들어 있고, 백로그의 개선 카드는 들어 있지 않아야 합니다. 들어 있으면 개선을 구현한 주가 기성이 오르고, 오픈 화면이 남은 주는 기성이 멈춰 보입니다.

멈춰 보이는 주를 만회하려고 개선 카드를 또 넣으면 악순환입니다. 기성 대상 목록을 오픈 범위 표와 1:1로 맞추세요.

맞춘 표 밖의 완료는 운영 백로그 완료로만 남깁니다. 운영 완료를 이번 사업 기성에 합산하지 않습니다.

합산하면 발주는 돈을 냈는데 오픈 화면이 비는 구조를 만듭니다.

운영 이관 백로그는 언제 가르나?

오픈 4주 전에 제품 백로그에서 이관 후 항목을 분리합니다. 분리하지 않으면 [[stabilization]] 기간이 남은 개발 목록이 됩니다. 남은 개발은 안정화가 아닙니다.

안정화는 결함과 운영 이벤트와 교육입니다. 새 화면 6본이 안정화 백로그 상단에 있으면, 그 4주는 구축의 연장입니다.

연장을 안정화로 부르지 마세요. 가르는 시점은 시험 착수 전후가 아니라 오픈 4주 전입니다.

4주 전에 못 넣은 항목은 이관 후 개선으로 날짜를 박습니다. 날짜 없이 보드 맨 아래에 두면 오픈 당일에도 살아 있습니다.

살아 있는 카드는 현업 눈에 미완료입니다. 미완료로 보이면 검수 서명이 미뤄지죠.

서명 미룸을 백로그 투명성으로 설명하지 않습니다. 설명 문장은 오픈 범위 표의 완료 행과 이관 후 목록 1장입니다.

두 장이 나란히 있어야 한 목록의 유혹이 끊깁니다.