Story point를 활용한 스크럼
개발 업무를 진행하면서 실제로 경험해봤거나 최소한 들어본 애자일 방법론은 SW 개발 방법의 주류로 자리 잡았다. 그중에 대부분이 스크럼을 활용하여 개발 업무를 진행하고 있다. 기본적인 워크플로우는 각 업무 환경에 따라 유동적으로 적용하여 활용하고 있다.
이번 포스트에서는 Story point를 활용한 스크럼 방법을 살펴볼 것이다. 들어가기에 앞서 기본적인 용어 설명은 밑에서 확인할 수 있다.
- 애자일(Agile) : 소프트웨어 개발론 중 하나로 프로젝트의 생명주기 동안 반복적인 개발을 통해 사용자 및 문제 정의, 테스트 및 문제 해결 등을 통해 개발하는 방법이다.
- 스크럼(Scrum) : 팀이 경험을 통해 배우고 이를 해결해 나가면서 스스로 발전해나가는 애자일 방법론의 프레임워크이다. 이를 통해 팀원들은 신속하게 문제를 해결할 수 있으며, 새로운 요구 사항에 대응할 수 있게 한다.
- 스프린트(Sprint) : 스크럼을 구성하는 기본 단위로 1~4주 단위의 반복적인(iteration) 개발 주기를 말한다.
- 사용자(User) : end-user뿐만 아니라 다른 팀 혹은 장치 등 스크럼 팀이 창출하는 가치를 이용하는 대상이다.
- 백로그(Backlog) : 목표를 달성하기 위해 작성된 작업 목록이다. 제품 백로그(Product Backlog, PB), 스프린트 백로그(Spring Backlog, SB) 등이 있다.
사용자 스토리 (User story)
[ 사용자 ] 는 [ 목적 ] 을 하기 위해 [ 작업 ] 을 할 것이다.
DoD (Definition of Done)
~~ 기능이 제공되어야 한다.
백로그를 표현하는 기법의 하나다. 사용자의 관점을 가지고 표현하기에 사용자와 개발자의 빠른 이해와 공유를 할 수 있다. DoD (Definition of Done)를 통해 해당 스토리가 완료되었는지 평가해야 한다.
스토리 포인트 (Story point)
사용자 스토리의 포인트를 의미하며, 각 스토리의 복잡성, 작업량, 비즈니스 지식, 불확실성 등을 수치화하여 부여한다.
추정 (Estimation)
사용자 스토리의 스토리 포인트를 부여하려고 할 때 어떻게 해야 좋은 추정을 할 수 있을까? 스토리 포인트를 부여하는 방법에는 여러 방법이 있다. 각 포인트당 특정 시간으로 환산하여 부여하거나, 특정 기준 스토리를 기준으로 상대적으로 더 얼마나 어려운가를 통해 부여할 수 있다. 추정 방법으로는 Planning poker, 유사 추정, 전문가 추정 등이 있다.
스토리 포인트에 대한 추정은 산정이 아니라 정확할 수 없을뿐더러 각 팀마다 스토리 포인트의 가치 척도가 다르기 때문에 스토리 포인트로 팀 간의 평가 척도로 사용될 수 없다.
좋은 추정
１. 좋은 사용자 스토리
좋은 추정을 하는 방법 중 하나는 좋은 사용자 스토리이다. 해당 스토리를 포인트로 추정할 때 스토리에 대한 이해와 정도 등이 적절하지 않다면 포인트로 추정하기 어렵기 때문이다. 그렇다면 좋은 스토리는 어떻게 작성할 수 있을까? 좋은 사용자 스토리의 조건은 INVEST라 할 수 있다.
- Independent - 다른 스토리와 독립적이어야 하며
- Negotiable - 유연한 의도로 표현되어야 하며
- Valuable - 고객에게 가치를 줄 수 있어야 하며
- Estimable - 추정 가능해야 하며
- Small - 반복(sprint, iteration) 주기에 적합한 작은 크기여야 하며
- Testable - 테스트 가능해야 한다
좋은 사용자 스토리를 토대로 기준 사용자 스토리를 설정해야 한다. 기준 사용자 스토리는 참여하는 스크럼 팀원들과 함께 정하고, 스토리 포인트를 부여한다. 해당 기준을 가장 작은 포인트로 설정 하였다면, 이를 기준으로 몇 배나 더 어려운지를 추정하여 포인트를 부여할 수 있다. 특정한 스토리가 너무 큰 수의 포인트가 추정된다면, 해당 스토리를 더 작게 나누어 포인트를 추정해야한다.
２. 좋은 추정 방법
좋은 추정을 하는 또 다른 방법 중 하나는 좋은 추정 방법이다. 위에서 언급한 여러 추정 방법이 있다. 각 팀원, 프로젝트, 비용 등에 따라 적합한 추정 방법을 활용해야 한다. 그중에서도 많은 스크럼 팀에서 활용되는 planning poker는 실제 작업하는 팀원만 참여하여, 스토리 포인트를 산정하여 추정한 포인트에 대한 적합도가 높게 나타날 수 있다.
활용해보기
Sprint workflow
- 이번 스프린트의 목표를 설정하며, PB(Product Backlog)에서 이번 Sprint에서 진행할 예비 SB(Sprint Backlog)를 선출한다.
- 이를 INVEST에 따라 User story를 작성한다.
- 팀의 Velocity(스프린트 당 팀이 획득할 수 있는 포인트)가 존재하다면 이를 참고하여 총 스토리 포인트를 정하며, 해당 정보가 없거나 부족하다면 이후 스프린트 때마다 이를 평가하여, 총 스토리 포인트를 정한다.
- Planning poker를 통해 기준 스토리 선정과 포인트 추정을 진행한다.
- 총 스토리 포인트만큼 스토리를 계획한다.
- Daily Scrum을 통해 팀원들의 진행 상황 및 이슈를 공유한다. 이를 통해 이슈의 해결 및 조정을 진행할 수 있다.
- 스프린트를 통해 진행된 결과물을 보여주고 이에 대한 리뷰를 진행한다.
- 스프린트를 진행한 팀원들은 이번 스프린트 과정에서 잘된 점, 잘 안된 점, 다음에 개선해야 할 점을 공유하고 토론한다.
참고문헌
https://en.wikipedia.org/wiki/Scrum_(software_development)
https://www.atlassian.com/ko/agile/project-management
https://engineering.linecorp.com/ko/blog/user-story-point-in-line-pay-team/
Leave a comment