일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- EVM
- 2010
- 달력
- 구성
- Server
- conf
- 설치
- 기간
- PMP
- ms project
- MSP
- 일정
- project server 2003
- install
- 2007
- 2막1장
- Outlook
- ff
- 비용
- WBS
- EPM
- project server 2010
- ms project 2016
- PMBOK
- 의존관계
- PROJECT
- project server
- 단위
- 완료율
- Sharepoint
- Today
- Total
MS Project
Scrum - User Story 본문
※ User Story 작성 기준 - 6가지.
1. Independent – 상호 독립적.
User Story의 Story Point 이중 추정을 방지하기 위해서 User Story 간에는 동일한 기능(작업 요소)이 포함서는 안됩니다. 서로 다른 User Story에 공통적인 작업 요소가 있다면 하나의 User Story에만 적용하고 다른 User Story에서는 그 요소를 가져다 활용합니다.
2. Negotiable – 변경 가능.
User Story는 언제든지 폐기, 추가, 변경 등이 가능하도록 구성하며, 실제로 구현할 때 필요한 세부 내용은 해당 스프린트 계획 미팅에서 확정합니다.
3. Valuable – 가치.
개발자가 아닌 일반인(고객과 사용자)이 알 수 있는 용어로 기술합니다.
4. Estimable – 산정 가능.
User Story는 규모 추정이 가능할 정도까지는 분할해야 합니다. Epic처럼 규모가 큰 요구사항은 추정이 어렵습니다. (분할과 통합 원리)
5. Small – 적절한 크기.
User Story는 Sprint 기간 안에 완료할 수 있을 정도의 규모로 구분(분할 또는 합산)되어야 힙니다.
6. Testable – 테스트가 가능한.
User Story는 구현을 검증할 수 있도록 테스트가 가능해야 합니다. (테스트 케이스를 작성할 수 있어야 합니다.)
“사용자는 검색 결과를 빠르게 확인할 수 있어야 한다” 라는 User Story는 테스트 케이스를 작성할 수 없습니다. “검색 결과는 1초 안에 화면에 표시되어야 한다” 로 기술되어야 합니다.