스프린트 회의 관련 간략 개념 정리


Concept 설명

비전 (Vision)

미래의 되고자 하는 모습에 대한 설명 (~이 되자)

  • e.g. 카카오 비전 : “Connect Everything” 새로운 연결, 더 나은 세상

사명 (Mission)

비전을 완수하는 방법 (~을 하자)

  • e.g. 구글의 미션 : 세상의 정보를 누구나 쉽게 사용하고 접근할 수 있게 한다.

목표 (Aim)

사명 완수가 가져다 주는 결과물

  • 각 step 별 목표
    • 사명 완수를 위해 각 step별의 목표를 설정
    • e.g. Milestone (M1)의 목표 : web의 사용성을 높인다.
    • e.g. Sprint (M1 S1)의 목표 : 거래하기 화면의 레이아웃 개선, 거래하기 화면에 보다 더 많은 정보를 제공

Milestone 정의

Sprint 회의를 하기 전 Milestone에 대해서 미리 정의가 되어 있으면 더 좋다.

  • Milestone 기간 : e.g. 3개월 (구체적으로 2020.06.15 ~ 2020.09.18)
  • 한 Sprint 기간 : e.g. 2주
  • 이번 Milestone이 몇 Sprint인지 : e.g. 6 Sprint
  • Milestone 목표 : e.g. web의 사용성을 높인다.
  • Milestone 달성을 위한 6 Sprint별 목표 : …
  • 이 목표는 절대적인 것은 아니다. 다른 더 급한 or 중요한 일을 해야 할 경우 Milestone 기간을 늘리거나, Sprint 목표를 몇 step씩 뒤로 보내고, 급한 걸 먼저 처리해야 한다. (이게 Agile의 핵심이다.)

업무 결정권자

  • 업무의 우선순위 결정권자수행시간 결정권자는 분리하여야 한다. (이건 ‘하는게 좋다’가 아니라 꼭! 그렇게 해야만 한다.)
    • 통상적으로 우선순위 결정권자 는 Project Owner (해당 팀의 CEO 역할)가 하고,
    • 수행시간 결정권자는 Engineering Manager (해당 팀의 CTO 역할)이 한다. Estimation은 각 작업자들에게 맡기더라도 그 책임자는 Engineering Manager이다.
  • 이 두가지 결정권이 1인에게 있으면 구성원들의 업무만족도를 보장하기 힘들다. 결국 팀원들의 이탈로 연결될 것이며, 해당 팀은 다시 원래 모습을 찾기 힘들어 질 수 있다.
  • 어쩔 수 없는 경우라면 해당 팀 Lead가 수행시간 결정권을 팀 내 다른 이에게 위임하는게 좋다. 단, 이것도 그 위임받은 구성원의 인사상 평가에 팀 Lead가 영향력을 행사할 수 있는 경우에는 소용없을 수 있다.
  • 그래도 어쩔 수 없다면 구성원들의 만장일치 합의로 결정하자.

Sprint 회의

  1. 지난 Sprint 회고
  2. Milestone 목표 선정 or 미리 선정된 목표 공유
  3. Action Item (Jira Ticket) 공유 : Sprint 회의 전에 미리 구성원들에게 공유되어 있으면 더 좋음
    • Action Item 들의 상관관계를 명확히 정의해 놓으면 작업시 도움이 된다. : associated, blocks, blocked
  4. Action Item 별 작업시간 Estimation
    • Estimation 방법 : 합의에 의한 결정 or 작업자가 판단
    • 초반에는 정확하게 예측하기 힘듬
    • 최대한 Action Item을 작은 단위 여러 개로 나누면 예측이 더 쉬워진다
    • 각 구성원들의 예측력이 떨어지더라도 계속 훈련시키는 것이 중요하다. - 단위 : Story Point. 보통 작업 시간으로 산정
  5. 각 작업자별 이번 Sprint의 Story Point 산정
    • 일별 Story Point x Working Day
    • 하루 8시간이더라도 집중해서 할 수 있는 시간으로 산정 (보통 하루 5 Story Point 정도가 적당할 것으로 예상)
    • 휴가 제외
    • 각종 Hotfix, 회의 등 Action Item 수행을 할 수 없는 시간을 미리 고려해야 함.
  6. 작업자에게 Action Item 할당
    • 보통 각자 시간을 주고 본인이 하고 싶은 Action Item을 스스로 가져가라고 한다. (본인이 하고 싶지 않더라도 본인이 스스로 자기가 하는게 가장 적합할 것이다 라고 판단하는 것도 가져간다면 더 성숙된 팀이라 할 수 있다.)
    • 개인 별 이번 Sprint Story Point 의 남은 여유분을 확인
    • 아직 할당되지 않은 Action Item을 배분
    • Estimation 시간을 따로 두지 않고, 이때 각자 Action Item을 가져가면서 스스로 Estimation하게 하는 방법도 있다. (아직 Estimation 하는 방법에 대해서 정해지지 않은 경우는 이렇게 하기도 한다.)
    • 초반에는 Story Point를 꽉채우지 않고, 조금 여유를 주는 방법도 있다.

Daily Scrum

  • Daily Scrum은 짧게 하는 것이 좋으며 (15분 이내), 아래 내용에 대해서 다루어야 한다.
  • 개인별 Action Item 수행내용에 대한 Review (Type A Review)
  • 예기치 못한 일에 대한 공유 : Sprint 기간 내 본인의 Action Item 수행이 힘들다 판단되면 Early Notice
  • 새롭게 알게 된 내용에 대해서 최대한 짧게 공유. 자세한 내용은 추후 따로 Show & Tell 로 구성
  • 때로는 본인이 어떤 일을 하면서 왜 그렇게 했는지에 대해서도 공유를 하면 다른 구성원들과 앞으로 이야기를 함에 도움이 된다. (Over Communication)
  • 어떤 공유 사항에 대해서 토의가 벌어지면 얼른 Parking Board에 적고 넘어가자. 그건 Scrum Meeting이 끝난 후 관련자들만 모여 다시 논의 (After Party)

1 on 1 meeting

  • 목적은 각 구성원들의 행복함을 유지시켜주는 것이다. (Mental Care)
  • 구성원 개인의 목표(Aim)의 수립을 도와준다. 회사/팀의 방향에 대해서 공유를 하면서 도와준다.
  • 매 Sprint별로 1회 정도가 적당하나, 상황에 따라 다르게 적용하되 최소 1달에 1번은 하는게 좋다.
  • 현재 맡고 있는 일에 대한 만족도, 어떤 어려움을 겪고 있는지, 하고 싶은 일은 어떤 것인지에 대한 feedback을 듣기 적합한 자리이다.
  • (바람직한것은 아니지만) 타인에 대한 불편한 감정을 이야기 할 수 있는 거의 유일한 자리이다.
  • 다른 구성원들과 마주치지 않도록 회사 밖, 다른 분위기에서 하는게 좋다.

기타 고려하면 좋은 것들

  • 회고에서 누군가(타인, 해당 자리에 없는 제3자 등…)에 대해서 비판, 비난하지 않아야 한다.
    • 비난하지 않으려면 모두가 여유가 있어야 한다.
    • 여유가 있기 위해서는 팀내의 경쟁심과 개인평가를 부추기는 방식을 버려야 한다.
  • 피드백을 잘하기 위해서는
    1. 잘 듣고 (적극적 경청 & 사실과 평가를 구분해서 듣기)
    2. 잘 이야기하기 (관찰한 사실 + I-Message로 자신의 판단/의견을 구분하여 말하기)
  • Sprint 기간 내 못한 Action Item에 대해서 해당 작업자를 비난하지 않아야 한다.
    • Sprint 의 책임자는 해당 Team Lead에게 있다.
    • 즉, 구성원이 못한 Action Item의 책임도 Team Lead이다.
    • Team Lead가 주말에 밤새워서라도 그 Action Item을 다 하는 것도 방법 중 하나이다. (최악의 방법이긴 하지만…)
    • 가능하면 각 구성원들이 자신이 맡은 Action Item들에 대해서 기간 내에 다 하지 못할 것이다라고 판단이 되었을 때 미리 팀 동료들에게 이야기를 하고 도움을 구하는게 좋다. (Early Notice)
    • 자신의 Action Item을 모두 끝낸 구성원은 다른 동료들에게 도움을 주는 것이 좋다.
      • 기술적 research가 필요한 경우 미리 알아봐서 시행착오의 시간을 대신 해준다.
      • 아직 시작하지 않은 Action Item을 대신 해준다.
      • 다른 도움이 필요한 동료가 없거나, 자신의 기술스택과 달라서 크게 도움이 되지 않는다면, 다음 Sprint의 Action Item을 미리 하는 방법도 있다. (이렇게 하려면 최소 다음 Sprint의 Action Item에 대해서 정의가 되어 있어야 한다. Estimation, 담당자 지정까지 다 되어 있으면 더 좋다.)
      • 여유가 있을 때 업무(work) 개선 뿐 아니라 팀운영(governance) 개선 활동도 할 수 있으면 팀 운영 효율화에 좋다.
    • 가능하면 Team Lead는 직접 Action Item을 맡지 않거나, 최소한으로 해서 구성원들이 도움을 요청했을 때 그들을 적극적으로 도와주는게 팀 전체 생산성을 높이는 방법이다.
  • 어떤 결정에 대해서 회의하고자 할 때 그 결정을 어떻게 결정할 것인지에 대해서 미리 고려를 하면 의사결정 시간을 줄일 수 있다. (Meta Decesion Making)
    • 만장일치 (모두 찬성)
    • 절대 다수 찬성 ( 2/3 찬성, 3/4 찬성 등…)
    • 다수결 (과반수 찬성)
    • 해당 작업자 결정
    • 다수의 의견을 들은 후 리더 결정 (사실상 그냥 리더 결정)
  • 바로 윗 항목에 나온 찬성 의 뜻을 미리 정의하여 공유하면 좋다.
    • e.g. 찬성은 반대 의사가 없음을 뜻함. 해당 의견을 지지하지는 못하더라도 기꺼이 수행할 수 있을 경우 찬성 이라는 표현을 사용한다. 등등…
  • 반대의견을 낼 경우 이유를 명확하게 설명해야 한다.
    • 저 방법 구려요. 요즘 스타일이 아니에요. X
    • A 방법을 택할 경우, B 작업이 너무 어려워 집니다. O
    • A 방법은 난이도가 너무 높아요. B 문제 해결에는 C 방법으로도 충분합니다. O
  • Agile 업무 종류
    • Type A : 통상적 업무 , Type B : A에 대한 개선 활동, Type C : B에 대한 개선 활동
    • Daily Scrum의 경우 원래 하는 일에 대한 Review (Type A)
    • Sprint 회고, Milestone 회고의 경우 : Type B , Type C

이 글이 도움이 되셨다면 공감 및 광고 클릭을 부탁드립니다 :)