User story

[who .. user role]로서 [what .. goal]을 달성하고 싶고, 그러면 [why .. reason] 할 수 있다

 

무엇이 좋은 스토리를 만드는가?

3 Cs : Card, Conversation, Confirmation

INVEST : Independent, Negotiable, Valuable, Estimable, Small, Testable

 

Independent

- 모든 스토리가 독립적이면 아무거나 뽑아서 개발 가능함

- 불가능하긴한데 최대한 독립적으로 해야 더 나은 백로그 작성 가능

 

Negotiable

- 너무 구체적으로 뭘 어떻게 할 지 적어두면 안됨

 

Valuable

- 유저와 비즈니스에 가치가 있어야 함

 

Estimable / Small

- 측정 가능해야 함 (Accecptance Criteria)

- 너무 크면 리스크가 커지니 분리해야 함, 그래야 측정하기도 쉬움

 

Testing

- Accecptance Criteria를 가지고 만족하는지 테스트할 수 있어야 함

---

Epics, Features, Stories

 

Epics

- 스프린트 또는 릴리즈에까지 걸치는 고수준의 기능 또는 활동

- ex. 데이터베이스 반응 시간 50%가량 향상

 

Features

- 기능의 구체적인 표현, 구현하기엔 너무 큼

- ex. 은행 고객으로서 수표를 입금할 수 있도록 지점을 찾는다

 

User Story

- 팀이 구현할 준비가 된 상태

- 은행 고객으로서, 이동을 최소화할 수 있도록, 특정 주소 근처에 있는 지점을 찾는다

 

User stories =/= Requirements

Requirement = User story + Conversations + Acceptance criteria + Supprting information

---

Value is influenced ..

- Time sensitivity

- Uncertainity & Risk

- Size

- External Dependency

 

---

Product backlog

- Adding User Stories

- Estimating & Elaborating

- Prioritizing

 

점진적인 정교화

Ideation (시장 트렌드, 프로토타입, 비전, ..)

=>

Maturation (유저 스토리 성숙, Acceptance criteria, prioritization)

=>

Execution (Sprint Planning, Sprint Estimation, Testing, Burndowns ..)

 

유저 스토리의 성숙

User stories -> Acceptance criteria -> Testable Examples -> Sprint Tasks

---

ATDD (Acceptance Test Driven Development)

팀 전체가 협력하여 acceptance criteria를 예제와 함께 논의하고,

이를 구체적인 acceptance tests 세트로 개발 전에 정제하는 실천 방법

 

키 특성

- 비즈니스 이해관계자들로부터 그들의 기대에 대한 세부 사항을 도출

- Acceptance Criteria를 자연어로 표현된 자동화 가능한 테스트로 정제

- 테스트를 SUT(테스트 대상 시스템)에 "글루"코드로 연결