엘리베이터 피치로 목표 확인, 사용자스토리로 의도파악(스크럼 마스터 2편)

엘리베이터 피치로 목표를 확인 하세요!
계획 수립에 많은 시간을 투자하지는 마세요!
사용자 스토리로 의도를 파악하세요!

실천편

개발 진척을 챙기면서 일정을 조율하는 사람이나, 다양한 의견을 수렴해서 윗선과 긴밀하게 소통할 수 있는 사람이면 프로젝트 오너로 적임자라 할 수 있습니다.

스크럼에서는 프로덕트 오너와 스크럼 마스터를 절대 겸임하지 마라고 합니다.
프로덕트 오너는 제품을 더 좋게 만드는데 주력하기 때문에 무의식적으로 개발자에게 무리한 부담을 줄 수 있습니다.
반면 스크럼 마스터는 일이 원활하게 돌아가도록 애써야 하기 때문에 개발자가 무리하는 걸 못 본척 하기 힘듭니다.
그런 상태가 지속되면 장기적으로 제품에 좋지 않은 영향을 주기 때문이죠.

인셉션 덱은 스크럼에는 포함되지 않지만, 목표와 과제를 명확히 정의할 때 자주 쓰는 기법입니다.
팀원 모두가 프로젝트를 이해하고 눈높이를 맞추는데 효과적입니다. 이때 정리된 내용은 큰 종이에 쓰거나 프레젠테이션 슬라이드로 만든 후 잘 보이는 곳에 붙여둡니다.

우선 목표를 확인하기 위해 엘리베이터 피치를 만들고 과제를 확인하기 위해 우리가 모인 이유를 설명합니다.

엘리베이터 피치
[영업의 달인]은 (project name)
[실시간으로 고객 정보를 확인] 하고 싶은 (need, opportunity)
[영업사원]을 위한 (target customer)
[업무지원 앱] 입니다. (product category)
이 제품은 [외근 중에도 업무] 를 할 수 있는데 (key benefit, reason to pay)
[이전 영업 지원 시스템] 과는 달리 (competitive, alternative)
[최신 정보 알림 기능] 이 차별화 포인트 입니다. (primary, differentiation)

스크럼을 하든 말든 작업 계획 수립만큼은 반드시 해야하는 중요한 작업인 거죠.

프로덕트 백로그는 할일을 기록해둔 작업 목록 같은 겁니다.
프로덕트 백로그 우선순위 높을수록 이런 내용이 많습니다.
– 제품의 핵심 기능
– 평범하지만 반드시 필요한 기능
– 원활한 개발을 위해 먼저 해야 하는 작업
– 이게 없으면 프로젝트를 할 의미가 없는 기능

스크럼에서 작업 순서를 책임지는 건 프로덕트 오너 입니다. 프로덕트 오너가 최종 확인하고 모두에게 공유하면 그때서야 비로소 최초의 프로덕트 백로그가 완성되는 거죠.

계획 수립 과정은 정말 중요 합니다. 하지만 필요 이상으로 많은 시간을 투자하진 마세요. 정작 주의해야 하는 건 중요한 작업을 빠뜨리지 않는 겁니다.

견적을 낼 때는 시간과 비용을 살피기보다 프로덕트 백로그의 각 항목을 처리할 때 필요한 작업량에 주목합니다.
특이한 점은 견적 작업을 개발자가 직접 한다는 겁니다.
작업량을 추정하다 보면 작업 방식에 대해 한번 더 생각해볼 기회가 되거든요.

많은 스크럼 팀이 견적을 낼 때 플래닝 포커를 사용합니다. 플래닝 포커를 할 때는 개발자 전원이 참석한 후 각자가 쓸 수 있는 카드를 나눠주죠.
카드엔 1,2,3,5,… 와 같은 피보나치 수가 적혀있습니다.

한 스프린트에서 끝낼수 있는 포인트 수를 벨로시티라고 합니다. 벨로시티는 정하는게 아니라 구하는 겁니다. 측정한단 말이죠.

완료조건이 없으면 프로덕트 오너는 작업이 끝났는지 판단할 수 없고, 개발자는 어디까지 작업해야 일이 끝나는지 확신할 수 없습니다.

데일리 스크럼(스탠드업 미팅)

• 스프린트 목표를 달성하기 위해 어제 한일
  스프린트 목표를 달성하기 위해 오늘 할일
  스프린트 목표를 달성하는데 방해되거나 도움이 필요한 일
• 데일리 스크럼을 잘하는 요령은 15분 안에 끝내는 겁니다.
• 문제가 나왔다고 데일리 스크럼 중에 해결하려 하거나 오랜시간 논의하려는 건 막아주세요. 별도의 회의에서 논의하게 유도하세요.

진척상황 관리는 태스크보드 및 번다운 차트를 활용

스프린트 리뷰에서는 스프린트 기간 중에 작업했던 일감과 완성된 결과물을 보여주고 다음 스프린트에서 반영할 피드백을 받아내야 합니다.

개발자의 관점은 완료조건에 녹아 있고, 프로덕트 오너의 관점은 프로덕트 백로그에 녹아있습니다.

스크럼의 모든 활동은 미리 정한 시간 안에 끝내는게 원칙입니다. 이걸 타임박스라고 하죠.

만약 스프린트가 예정보다 빨리 끝났다면 평소에는 바빠서 엄두도 내지 못한 소스코드 리팩터링 이나 테스트 자동화를 해보세요.
아니면 뒤에 남은 개발 분량 중 미리 할만한게 있는지 프로덕트 백로그를 살펴보세요.(물론 프로덕트 오너에게 명세 확인 필요)

회고는 팀의 지난 활동을 돌아보고 다음 활동을 개선하는 대단히 미래 지향적이고 적극적인 활동입니다. 사소하더라도 잘된 점을 찾는것도 중요하다.

스크럼 팀 입장에서는 벨로시티를 안정되게 유지하고 싶은데 주변에서 올리라는 압박이 있을 수 있습니다.
하지만 그런 얘기에는 귀를 기울이지 마세요. 억지로 벨로시티를 올리려고 하면 그만큼 부작용도 뒤따릅니다.

사용자 스토리는 이런 기능이 필요해와 같이 what만 언급하는게 아니라 뭘하기 위해서다라고 why의 의도를 전달하고 있습니다.
– 난 [어떤 사용자] 인데,
– [어떤 기능이나 성능]이 필요해,
– 그건 [어떤 일을 달성] 하기 위해서야.

애자일 스크럼 현황판

예를 들어 프로덕트 오너가 프로덕트 백로그의 항목을 제대에 조정하지 않는 건 문제로 봅니다.
반면 알고 보니 프로덕트 오너가 다른 일이 바빠 프로덕트 백로그를 손볼 시간이 없다면 그러한 문제를 유발하는 원인을 장애물로 보는 거죠. 장애물을 제거하면 문제는 줄어들고 스크럼 팀은 이상적인 모습에 다가설 수 있습니다.

스크럼이 바라는 건 그건 제 담당이 아닌데요라고 말하는 대신 모두가 협력해서 작업하는 모습입니다.
어려움이 있으면 이야기하고 좋지 않은 상황일수록 협력하고 극복하는게 진정 바람직한 팀의 모습이라 할 수 있습니다.

하나의 일감을 여러 명의 팀원과 함게 작업하는 것을 스워밍이라고 합니다. 지식공유와 기술 이전이 자연스럽게 이루어집니다.
한예로 몹 프로그래밍이라는 개발방법이 있습니다. 팀원 모두가 함께 모여 같은 일을, 같은 시간에, 같은 공간에서, 같은 컴퓨터로 개발하는 방법이죠.

스크럼 팀의 결정을 존중하는 데는 이유가 있습니다. 프로젝트를 하다 보면 다양한 의사결정이 필요한데요.
실제로 작업할 사람이 아니면 제대로 된 판단을 하기 힘듭니다. 왜냐하면 제삼자는 실무자만큼 현장 상황을 잘 알지 못하기 때문입니다.

커밋먼트는 반드시 달성해야하는 것도 무리해서 지켜야 하는 것도 아닙니다. 단지 팀원 스스로가 해야할일에 최선을 다하리라고 약속해주기를 바랄 뿐입니다.

실패가 용인되지 않으면 오히려 부작용이 생기는 걸 잊지 맙시다. 스크럼이 바라는 건 커밋먼트를 반드시 지키는게 아니라 책임감을 가지고 최선을 다하는 모습입니다.

단 스프린트 회고가 익숙지 않을 때는 스프린트 중에 발생한 문제를 해결하려 하는 경향이 있습니다.
일하는 방식을 개선하는 이벤트가 아닌 문제를 해결하기 위한 이벤트로 변질된다는 얘기죠.