사용자 스토리는 작업 항목을 사용자의 관점에서 기술적이지 않은 언어로 설명할 때 사용됩니다. {type of user}(으)로서 나는 {receive benefit}을(를) 위해 {goal}을(를) 원합니다.

웹사이트를 간단한 예제로 사용하여 사용자 스토리를 만들어 보겠습니다.

고객으로서 이전에 구입한 내용을 볼 수 있도록 계정을 만들고 싶습니다.

일반적으로는 제품 소유자가 사용자 스토리를 구상해 우선 순위를 정하며, 개발팀은 다가오는 스프린트에서 스토리를 완료하는 데 필요한 세부 작업을 결정합니다. 또한, 스토리 작업을 완료하는 데 필요한 상대적 노력을 추정하는 것도 개발팀의 몫입니다.

스크럼에서 팀은 스프린트라고 하는 정해진 기간 동안 일련의 사용자 스토리 또는 기타 작업 항목을 완료하기 위해 예측을 합니다. 일반적으로 스프린트의 길이는 1주, 2주 또는 4주입니다. 스프린트 길이는 팀의 선택에 달려 있으며 2주로 시작하는 것이 좋습니다. 2주는 무언가를 달성할 정도로는 길지만 팀이 정기적인 피드백을 받을 정도로 긴 기간은 아닙니다. 스프린트 케이던스가 결정되면 팀은 해당 케이던스로 끊임없이 작업합니다. 시간이 고정된 스프린트는 추정 기술을 강화하고 팀이 백로그에서 작업할 때 향후 속도를 예측합니다.

참석자: 필수: 개발 팀, 스크럼 마스터, 제품 소유자

언제: 스프린트가 시작될 때

기간: 일반적으로 주당 2시간의 반복(예: 4시간의 계획 회의와 함께 2주간의 스프린트가 시작됨). 목적을 달성하면 회의는 종료됩니다.

목적: 스프린트 작업을 계획합니다. 팀은 스프린트 목표와 스프린트 백로그에 합의합니다.

스프린트를 만들 때 제품 소유자는 일반적으로 스프린트의 목표를 파악합니다. 그러면 스프린트에서 완료해야 할 작업의 테마가 제공됩니다. 스프린트 목표는 스프린트에서 완료되는 스토리의 수에 유연성을 제공하기도 합니다. 스프린트 목표를 달성하면 스프린트가 성공으로 간주됩니다.

기존의 소프트웨어 팀은 며칠, 몇 주, 몇 달이라는 시간 형식에 따라 추정치를 제공합니다. 하지만 많은 애자일 팀이 스토리 포인트로 전환했습니다. 스토리 포인트는 종종 피보나치수열과 같은 형식(0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100)으로 작업에 드는 상대적 노력을 평가합니다.

(주) 참석자: 개발 팀

언제: 하루에 한 번(주로 아침)

기간: 15분을 넘지 않습니다. 회의실을 예약하지 말고 앉아서 스탠드업 회의를 진행하세요. 스탠드업 회의를 하면 회의 시간을 짧게 유지할 수 있습니다.

목적: 매일 스탠드업 회의는 팀 전체에서 무슨 일이 일어나고 있는지 모두에게 빠르게 알리고 그날의 작업을 계획하기 위해 고안되었습니다. 완벽한 상태 회의가 아닙니다. 분위기는 가볍고 재미있지만 유익해야 합니다. 각 팀원에게 다음 질문에 대답하도록 안내합니다.

• 어제 어떤 작업을 완료했습니까?

• 오늘 무슨 일을 할 예정입니까?

• 무언가에 의해 차단됐습니까?

어제 완료한 작업을 동료들 앞에서 보고하는 데에는 암묵적인 책임이 있습니다. 항상 같은 일을 하며 진전을 이루지 않는 팀원이 되고 싶은 구성원은 없습니다.

전문가 팁: 일부 팀에서는 타이머를 사용하여 모든 관계자를 추적합니다. 또 어떤 팀은 팀 전체에 질문을 던져 모두가 관심을 기울이고 있는지 확인합니다. 많은 분산된 팀이 화상 회의 또는 그룹 채팅을 사용하여 거리 격차를 줄입니다. 팀이 제각기 고유하듯이 스탠드업 회의 역시 고유합니다.

번다운 차트는 스프린트에서 수행해야 할 실제 작업량과 예상 작업량을 보여줍니다. 번다운 차트의 가로 x축은 시간을 나타내고 세로 y축은 일반적으로 스토리 포인트를 나타냅니다.

번다운 차트를 사용하여 스프린트의 남은 총 작업을 추적하고 스프린트 목표 달성 가능성을 예측할 수 있습니다. 반복 과정에서 남은 작업을 추적하여 팀은 진행률을 관리하고 그에 따라 대응할 수 있습니다.

• 팀이 충분한 작업에 대한 이행 약속을 하지 않기 때문에 스프린트마다 작업을 일찍 완료합니다.

• 팀이 너무 많은 작업에 대해 이행을 약속하기 때문에 스프린트마다 예측에 미달하고 있습니다.

• 번다운 차트 라인은 작업이 세부적인 작업으로 분할되지 않았기 때문에 점진적인 번다운 차트가 아닌 가파른 하락으로 이어집니다.

• 제품 소유자가 스프린트 중에 범위를 추가하거나 변경합니다.

스프린트 보고서에는 번다운 차트가 포함되며 완료된 작업, 완료되지 않은 작업 및 스프린트가 시작된 후 추가된 작업이 나열됩니다.

(주) 참석자: 개발 팀, 스크럼 마스터, 제품 소유자.

선택 사항: 이해 관계자

언제: 일반적으로 스프린트의 마지막 날

기간: 일반적으로 2주 스프린트의 경우 2시간

목적: 증분을 검사하고 협업을 통해 제품 백로그를 업데이트합니다.

물어봐야 할 질문:

• 팀이 스프린트 예측을 달성했습니까?

• 스프린트 중에 작업이 추가되거나 제거되었습니까?

• 스프린트 내에서 완료되지 않은 작업이 있습니까?

• 그렇다면 왜 그렇습니까?

참석자: 개발 팀, 스크럼 마스터, 제품 소유자

언제: 반복이 끝날 때

기간: 일반적으로 2주 스프린트의 경우 90분

목적: 팀은 프로세스, 도구 및 팀 상호 작용을 포함하여 자체적으로 검사합니다. 다음 스프린트의 백로그에 개선 이슈가 추가되는 경우가 많습니다.

회고는 조치 없이 불만을 제기하는 시간이 아닙니다. 회고를 통해 무엇이 효과가 있는지 파악하여 팀이 해당 영역에 계속 집중할 수 있도록 하세요. 또한 효과가 없는 것이 무엇인지 알아보고 이 시간을 통해 창의적인 해결 방법을 찾고 실행 계획을 수립하세요. 지속적인 개선은 애자일 팀 내에서 발전을 유지하고 추진하는 요소이며, 여기에서 핵심적인 부분은 회고입니다.

물어봐야 할 질문:

• 스프린트 중에 잘된 점은 무엇입니까?

• 부족한 점은 무엇이었습니까?

• 다음 번에는 무엇을 더 잘할 수 있습니까?

전문가 팁: 팀 전체에서 작업이 잘 진행되고 있더라도 회고를 중단하지 마세요. 회고는 팀이 계속해서 잘 진행할 수 있도록 지속적으로 안내해 줍니다.