User Story Collaboration – Achieving Shared Understanding
1. Introduction
In agile development, user stories are not meant to be fully detailed specifications.
Instead, they act as a starting point for collaboration, helping the team build a shared understanding of what needs to be delivered.
애자일에서 사용자 스토리(User story)는 완전한 명세서가 아니라, 팀 간 협업을 시작하기 위한 도구입니다.
이 문제는 팀이 무엇을 만들어야 하는지에 대한 공동 이해를 어떻게 형성하는지를 묻습니다.
2. Practice Question
❓ Question
Which collaborative user story writing practice enables the team to achieve a collective understanding of what needs to be delivered?
- a) Planning poker, so that a team can achieve consensus on the effort needed to implement a user story
- b) Reviews, so that a team can detect inconsistencies and contradictions in a user story
- c) Iteration planning, so that user stories with the highest business value for a customer can be prioritized for implementation
- d) Conversation, so that team members can understand how the software will be used
✅ Correct Answer: d)
3. Explanation
✔ d) Conversation — Correct
User stories are often explained using the Three Cs concept:
- Card – a brief written description
- Conversation – discussions about details and usage
- Confirmation – acceptance criteria
Conversation is the key practice that allows:
- Developers, testers, and business stakeholders to discuss expectations
- Clarification of how the software will be used
- Creation of meaningful acceptance criteria
Through conversation, the team develops a shared vision of what should be delivered.
사용자 스토리는 흔히 3C(Card–Conversation–Confirmation)로 설명됩니다.
이 중 Conversation(대화)은 팀 구성원들이 소프트웨어 사용 방식을 이해하고,
무엇을 만들어야 하는지에 대한 공동된 이해를 형성하게 해주는 핵심 요소입니다.
❌ a) Planning poker — Incorrect
Planning poker is used to estimate effort for an already defined user story.
It helps with sizing and consensus, but not with understanding what needs to be delivered.
플래닝 포커는 구현 난이도나 노력을 추정하기 위한 기법으로,
무엇을 만들어야 하는지 이해하는 데 목적이 있지는 않습니다.
❌ b) Reviews — Incorrect
Reviews help detect inconsistencies or ambiguities in existing documents.
However, reviews are not a collaborative user story writing practice as defined in agile methods.
리뷰는 문서 품질을 점검하는 활동이지,
애자일 사용자 스토리 작성의 핵심 협업 기법은 아닙니다.
❌ c) Iteration planning — Incorrect
Iteration planning focuses on:
- Prioritizing user stories
- Selecting work for the next iteration
It is a planning activity, not a practice for understanding story details.
이터레이션 계획은 작업 우선순위를 정하는 프로젝트 관리 활동으로,
사용자 스토리의 의미를 이해하는 목적은 아닙니다.
4. Summary Table
| Practice | Main Purpose | Builds Shared Understanding? | 요약 |
|---|---|---|---|
| Planning poker | Effort estimation | ✖ No | 추정 기법 |
| Reviews | Find inconsistencies | ✖ No | 검토 활동 |
| Iteration planning | Prioritization | ✖ No | 계획 수립 |
| Conversation | Discuss usage and expectations | ✔ Yes | 공동 이해 |
5. Final Takeaway
For the ISTQB exam, remember this key idea:
User stories achieve shared understanding through conversation. Talking about how the software will be used is more important than the written text alone.
시험 대비 핵심 문장입니다.
사용자 스토리에서 공동된 이해를 만드는 핵심은 문서가 아니라 ‘대화(Conversation)’이다.
Related: More ISTQB Posts | Next Question