← Semua pelajaran

Pelajaran #7: Project Scope Definition + User Story Writing

5 November 2026

Selamat pagi. Hari ini kita lanjut workflow Turn ideas into build plans, bagian 3 dari 6. Dua prompt berikutnya: Project Scope Definition dan User Story Writing. Kemarin kita sudah memetakan perjalanan pengguna dan menggabungkan riset. Hari ini kita menetapkan batas proyek, lalu mengubah batas itu jadi cerita pengguna yang siap dikerjakan. Halaman workflow lengkapnya ada di katalog workflow ini.

Teks prompt di bawah ini disalin lengkap dari halaman katalognya, siap ditempel ke AI tool pilihanmu.

1. Project Scope Definition

Apa itu dan kapan dipakai

Ini prompt untuk menetapkan batas proyek secara tertulis sebelum kamu mulai membangun. Pakai setelah masalah, perjalanan pengguna, dan riset sudah jelas, saat kamu perlu menjawab pertanyaan ini: apa yang dikerjakan, apa yang sengaja tidak dikerjakan, dan kapan proyek ini bisa disebut selesai. Cocok dipakai sebelum menambah satu fitur ke BugarKu atau ke aplikasi Kumbang, supaya fitur itu tidak melebar di tengah jalan.

Mengapa bekerja

Prompt ini bekerja karena ia memaksa tiga hal ditulis eksplisit. Pertama, konteks proyek: nama proyek, masalah yang diselesaikan, siapa penggunanya, jadwal, dan sumber daya. Kedua, batas yang dikerjakan dan batas yang tidak dikerjakan, masing masing dengan alasannya. Ketiga, asumsi, kendala, kriteria sukses, proses perubahan batas, dan persetujuan. Karena yang tidak dikerjakan ditulis sama jelasnya dengan yang dikerjakan, permintaan tambah fitur di tengah jalan jadi gampang dinilai: masuk batas atau di luar batas. Perhatian: prompt ini hanya sebagus inputnya. Kalau kolom konteks dibiarkan kosong, AI akan mengarang fitur dan asumsi yang terdengar rapi tapi bukan keputusanmu. Isi dulu, lalu periksa tiap baris sebelum dipakai.

Teks prompt

You are a product manager helping me define clear scope for a project. I need explicit boundaries to prevent scope creep and align stakeholders.

Project Context:

- Project name: [Your project]
- Problem being solved: [The core problem]
- Target users: [Who this is for]
- Timeline: [Expected duration]
- Resources: [Team and constraints]

Please help me define comprehensive scope:

1. Project Overview

   One-sentence summary:

   [What we're building and why]

   Success statement:

   "This project is successful when [specific, measurable outcome]"

2. In Scope (Explicitly)

   Features & Functionality:

   • [Feature 1]: [Brief description]
   • [Feature 2]: [Brief description]
   • [Feature 3]: [Brief description]

   User Flows:

   • [Flow 1]: [Brief description]
   • [Flow 2]: [Brief description]

   Platforms/Environments:

   • [e.g., Web, iOS, Android]
   • [e.g., Production only, or includes staging]

   User Segments:

   • [Which users this applies to]

   Integrations:

   • [Systems that must integrate]

3. Out of Scope (Explicitly)

   NOT building:

   • [Feature explicitly excluded]: [Why]
   • [Feature explicitly excluded]: [Why]
   • [Feature explicitly excluded]: [Why]

   NOT addressing:

   • [User need explicitly deferred]: [Why/when it might be addressed]
   • [Edge case explicitly excluded]: [Why]

   NOT supporting:

   • [Platform/browser/device]: [Why]
   • [User segment]: [Why]

   Future consideration:

   - [Item for potential future phase]
   - [Item for potential future phase]

4. Scope Boundaries

   | Decision Point | In Scope | Out of Scope | Rationale |
   |----------------|----------|--------------|-----------|
   | [Example: User types] | Admins, Members | Guests | MVP focused on core users |

5. Assumptions

   We are assuming:

   • [Technical assumption]: [Impact if wrong]
   • [User assumption]: [Impact if wrong]
   • [Business assumption]: [Impact if wrong]
   • [Resource assumption]: [Impact if wrong]

   Dependencies:

   • [Dependency]: [Owner, risk if not met]

6. Constraints

   Hard constraints (cannot change):

   - [Timeline constraint]
   - [Budget constraint]
   - [Technical constraint]
   - [Regulatory constraint]

   Soft constraints (prefer to maintain):

   - [Preferred constraint]

7. Success Criteria

   Minimum viable scope (must have for launch):

   • [Requirement 1]
   • [Requirement 2]
   • [Requirement 3]

   Target scope (plan to include):

   • [Additional item 1]
   • [Additional item 2]

   Stretch scope (if time permits):

   • [Nice to have 1]
   • [Nice to have 2]

8. Scope Change Process

   If scope change is requested:

   1. Document the change request
   2. Assess impact on timeline, resources, other scope
   3. Get approval from [decision maker]
   4. Update scope document and communicate

   Triggers for scope discussion:

   - [Scenario that would require revisiting scope]

9. Sign-off

   This scope is agreed by:

   - Product: [Name, Date]
   - Engineering: [Name, Date]
   - Design: [Name, Date]
   - Stakeholders: [Name, Date]

Contoh terisi

Kasus Aulia: menambah panduan posisi tubuh ke BugarKu. Konteksnya: pengguna rumahan yang berlatih sendiri lewat kamera HP, dikerjakan sendiri, target selesai dalam satu putaran perbaikan. Yang dikerjakan: layar panduan posisi tubuh sebelum latihan dimulai, indikator tubuh sudah terdeteksi atau belum, dan tombol mulai yang aktif setelah tubuh terdeteksi. Yang tidak dikerjakan: penilaian gerakan otomatis penuh, mode pelatih live, dan riwayat latihan. Alasannya ditulis jelas: ketiganya butuh kerja terpisah dan bukan sumber kebingungan utama pengguna sekarang. Asumsinya: kamera HP bisa diakses lewat browser dan pengguna berlatih di ruang yang cukup terang. Kendala yang tidak bisa diubah: harus jalan di HP Android dan iPhone lewat browser, tanpa instalasi. Kriteria suksesnya: pengguna bisa mulai satu set penuh tanpa berhenti karena bingung posisi tubuh.

Tugas praktik hari ini

Pilih satu fitur kecil dari BugarKu atau satu aplikasi Kumbang. Tulis batasnya dalam tiga bagian pendek: apa yang dikerjakan, apa yang sengaja tidak dikerjakan beserta alasannya, dan satu asumsi yang paling berisiko kalau ternyata salah.

2. User Story Writing

Apa itu dan kapan dipakai

Ini prompt untuk mengubah satu fitur menjadi cerita pengguna yang siap dikerjakan. Pakai setelah batas proyek ditetapkan, saat kamu perlu menjelaskan satu fitur dari sudut pandang pengguna, bukan dari sudut pandang kode. Cocok dipakai sebelum kamu atau agen coding mulai menulis kode untuk satu fitur, supaya yang dibangun sesuai dengan kebutuhan pengguna dan bisa diuji.

Mengapa bekerja

Prompt ini bekerja karena satu cerita dipaksa lengkap dari empat sisi. Pertama, format cerita: siapa penggunanya, apa yang ia inginkan, dan manfaat apa yang ia dapat. Kedua, kriteria penerimaan yang spesifik dan bisa diuji, termasuk jalur normal, kasus pinggiran, dan kondisi gagal. Ketiga, alur pengguna langkah demi langkah, dari titik masuk sampai titik keluar, termasuk jalur alternatif. Keempat, pertimbangan teknis, kebutuhan desain, metrik sukses, dan cerita terkait. Karena kriteria penerimaannya ditulis sebelum kode ditulis, kamu punya cara yang jelas untuk menyatakan satu fitur sudah selesai atau belum. Perhatian: cerita yang personanya samar akan menghasilkan kriteria yang generik. Tulis personanya spesifik, misalnya pengguna baru yang berlatih sendiri di rumah, bukan sekadar pengguna.

Teks prompt

Write user stories for [feature/epic name].

Context:

- User persona: [describe]
- Business goal: [describe]
- Feature description: [describe]

Provide:

1. User Story Format

   - As a [persona]
   - I want to [goal]
   - So that [benefit/value]

2. Story Details

   - Story title
   - Description
   - User persona context
   - Business value
   - User value

3. Acceptance Criteria

   - Specific, testable criteria
   - Happy path scenarios
   - Edge cases
   - Error states
   - Success conditions

4. User Flow

   - Step-by-step user journey
   - Entry points
   - Decision points
   - Exit points
   - Alternative paths

5. Technical Considerations

   - Technical requirements
   - Dependencies
   - Constraints
   - Integration points

6. Design Requirements

   - UI/UX requirements
   - Design system components
   - Responsive considerations
   - Accessibility requirements

7. Success Metrics

   - How to measure success
   - Key performance indicators
   - User satisfaction metrics
   - Business impact metrics

8. Related Stories

   - Dependencies
   - Related features
   - Follow-up stories

Format as ready-to-use user stories with complete acceptance criteria.

Contoh terisi

Sebagai pengguna baru BugarKu yang berlatih sendiri di rumah, saya ingin melihat panduan posisi tubuh sebelum latihan dimulai, supaya saya tahu tubuh saya sudah masuk frame kamera.

Kriteria penerimaan:
1. Panduan posisi tubuh muncul sebelum tombol mulai bisa ditekan.
2. Indikator di layar berubah jelas saat tubuh sudah terdeteksi kamera.
3. Kalau kamera tidak memberi gambar, layar menampilkan pesan yang menjelaskan apa yang harus dilakukan pengguna.
4. Kalau tubuh hanya sebagian masuk frame, layar memberi tahu bagian mana yang keluar frame.

Cerita ini diambil dari batas proyek pada prompt pertama tadi. Satu fitur, satu persona, satu manfaat, dan empat kriteria yang semuanya bisa diuji langsung di HP.

Tugas praktik hari ini

Ambil batas proyek yang kamu tulis untuk tugas pertama tadi. Ubah satu fiturnya menjadi satu cerita pengguna lengkap dengan tiga kriteria penerimaan yang bisa diuji. Kalau satu kriteria tidak bisa diuji langsung, tulis ulang sampai bisa.

Besok kita lanjut ke prompt ketujuh dan kedelapan workflow ini.