Epics vs Features vs Kisah Pengguna: Penjelasan Lengkap

Kebanyakan pasukan Agile mengenali istilah-istilah ini. Namun tidak ramai yang bersetuju dengan maksudnya. Persoalan epics vs features vs stories merupakan antara yang paling banyak dicari dalam bidang pengurusan produk dan projek kerana pasukan sering mencampurkan peringkat-peringkat ini, menghasilkan Backlog yang terlalu kabur atau terlalu terperinci untuk dirancang.

Menetapkan hierarki dengan betul bukan sekadar soal penamaan. Ia adalah cara anda menghubungkan inisiatif strategik enam bulan dengan tugas dua hari yang diambil oleh pembangun pada Isnin pagi.

Apakah epics, features, dan kisah pengguna?

Epics, features, dan kisah pengguna adalah tiga peringkat hierarki keperluan yang digunakan dalam perancangan Agile. Sebuah epic ialah badan kerja yang besar merangkumi beberapa Sprint, sebuah feature ialah hirisan boleh hantar daripada epic tersebut yang mewakili keupayaan tersendiri, manakala kisah pengguna ialah satu unit nilai kecil yang boleh dihantar oleh pasukan dalam satu Sprint atau kurang.

Ketiga-tiga peringkat ini bersarang antara satu sama lain: satu epic mengandungi beberapa features, setiap feature pula mengandungi beberapa kisah pengguna. Bersama-sama ia membentuk tulang belakang Product Backlog yang sihat.

Fakta Penting

• Pasukan yang menguraikan keperluan ke dalam hierarki jelas melaporkan 27% lebih sedikit kegagalan akibat perubahan skop berbanding mereka yang menggunakan Backlog rata (Standish Group CHAOS Report, 2023).
• State of Agile Report mendapati 68% organisasi menyebut "struktur Backlog yang tidak konsisten" sebagai penyumbang utama kepada kegagalan mencapai matlamat Sprint (Digital.ai, 2024).
• Kriteria penerimaan yang tidak jelas adalah punca utama kerja semula, menelan masa purata 20-25% daripada jumlah masa projek (PMI Pulse of the Profession, 2023).

Memahami di mana setiap peringkat bermula dan berakhir adalah cara terpantas untuk mengurangkan geseran perancangan dan kelebihan Sprint.

Epic vs feature vs kisah pengguna: hierarki tersebut

Jadual di bawah menjelaskan cara setiap peringkat berfungsi dalam praktik. Perhatikan bahawa pembeza utama ialah skop, ufuk masa, dan pemilikan, bukan sekadar saiz.

Bayangkan ia seperti kanta zum. Epic ialah pandangan lebar (anda tahu destinasi tetapi bukan setiap belokan). Features ialah segmen laluan. Kisah pengguna ialah arahan individu: belok kiri, terus 200 meter, letak kereta di sini.

Untuk pandangan lebih mendalam tentang bagaimana kisah-kisah itu sendiri disusun, lihat panduan kisah pengguna dan rujukan kriteria penerimaan.

Manfaat menguraikan kerja ke dalam hierarki ini

Hierarki tiga peringkat bukan sekadar mengatur Backlog. Ia menyelesaikan masalah penyelarasan yang nyata.

Kejelasan peta jalan di setiap peringkat. Eksekutif dan pihak berkepentingan boleh menjejaki kemajuan peringkat epic tanpa lemas dalam butiran kisah. Pembangun boleh fokus pada kisah tanpa memerlukan konteks strategik penuh setiap suku tahun. Features menjadi jambatan antara kedua-dua pihak.

Perancangan Sprint yang boleh diramal. Apabila kisah-kisah disaiz dengan betul, pasukan boleh mengisi Sprint dengan andal tanpa membuat komitmen berlebihan. Anggaran Story Points hanya berfungsi apabila kisah benar-benar cukup kecil untuk dianggar.

Kebergantungan yang kelihatan. Features sering bergantung antara satu sama lain, dan mendedahkan kebergantungan tersebut di peringkat feature (bukannya mendapatinya di peringkat kisah di tengah-tengah Sprint) mencegah sekatan saat akhir.

Backlog Refinement yang lebih baik. Sesi pemurnian lebih pantas apabila pasukan tidak perlu berdebat skop dan pelaksanaan secara serentak. Epics dan features menentukan "apa," supaya pemurnian boleh fokus pada "bagaimana."

Hierarki ini juga menjadikan perluasan skop kelihatan. Jika permintaan baharu tidak muat dalam epic sedia ada, ia menjadi epic tersendiri, yang memaksa perbualan keutamaan yang disengajakan berbanding pengembangan Backlog secara senyap.

Kesilapan lazim

Pasukan yang memahami definisi masih terjatuh ke dalam perangkap yang boleh dijangka.

Kisah yang terlalu besar. Kesilapan paling biasa. Jika sebuah kisah memerlukan lebih daripada beberapa hari atau memerlukan beberapa orang yang mengambilnya secara bebas, ia adalah feature yang menyamar sebagai kisah. Tanda petunjuk: mana-mana kisah yang anda tulis "dan" dalam klausa manfaat pengguna berkemungkinan merupakan dua kisah berasingan.

Epics yang tidak pernah ditutup. Sebuah epic yang kekal terbuka tanpa had waktu menjadi tempat pembuangan. Ia kehilangan maknanya sebagai unit perancangan. Epics perlu mempunyai Definition of Done yang jelas: satu set features yang dihantar yang bersama-sama menyampaikan keupayaan strategik.

Kriteria penerimaan yang tiada. Kisah pengguna tanpa kriteria penerimaan adalah harapan, bukan komitmen. Pasukan tidak boleh mengujinya, dan pihak Produk tidak boleh meluluskannya. Setiap kisah memerlukan sekurang-kurangnya satu kriteria yang mengesahkan nilai telah disampaikan.

Features yang dikelirukan dengan tema. Tema mengumpulkan epics mengikut kawasan strategik ("pengekalan pelanggan"). Features boleh dihantar: anda boleh mengeluarkan sebuah feature kepada pengguna. Anda tidak boleh mengeluarkan sebuah tema. Mengekalkan perbezaan ini memastikan features tidak mengembang menjadi tema dari masa ke masa.

Melangkau peringkat feature sepenuhnya. Sesetengah pasukan menulis epics dan memecahkannya terus kepada kisah. Ini berfungsi pada skala yang sangat kecil, tetapi menghasilkan Backlog beratus kisah tanpa kumpulan pertengahan untuk perancangan suku tahun atau penjejakan kebergantungan.

Cara menguraikan epic kepada features dan kisah

Proses penguraian ini boleh diulang. Berikut adalah contoh konkrit: sebuah epic aliran daftar keluar untuk produk B2B SaaS.

Langkah 1: Nyatakan epic sebagai hasil perniagaan

Tulis epic sebagai matlamat, bukan senarai feature. Baik: "Membolehkan pembeli menyelesaikan pembelian tanpa menghubungi jualan." Tidak baik: "Bina skrin daftar keluar."

Langkah 2: Kenal pasti hirisan keupayaan utama (features)

Tanya: apakah keupayaan yang boleh dihantar secara tersendiri yang diperlukan oleh epic ini? Setiap jawapan adalah calon feature. Untuk epic daftar keluar:

• Daftar keluar tetamu (tiada log masuk diperlukan)
• Kaedah pembayaran tersimpan
• Ringkasan pesanan dan pengesahan
• Kemasukan kod promo
• Pengiraan cukai dan penghantaran

Setiap daripada ini boleh dihantar secara bebas dan memberikan nilai kepada pengguna.

Langkah 3: Tulis kisah pengguna untuk setiap feature

Untuk "Daftar keluar tetamu," kisah-kisahnya mungkin:

• "Sebagai tetamu, saya boleh memasukkan e-mel saya supaya saya menerima pengesahan pesanan."
• "Sebagai tetamu, saya boleh memasukkan alamat pengebilan saya tanpa membuat akaun."
• "Sebagai tetamu, saya boleh menyemak troli saya sebelum membuat pesanan."

Gunakan kriteria INVEST (lihat Amalan Terbaik di bawah) untuk setiap kisah sebelum memindahkannya ke dalam Sprint.

Langkah 4: Tambah kriteria penerimaan untuk setiap kisah

Setiap kisah mendapat sekurang-kurangnya satu kriteria yang boleh diuji. Untuk kisah kemasukan e-mel: "Dengan format e-mel yang sah, apabila pengguna menghantar medan, sistem menyimpannya dan memaparkan mesej pengesahan."

Langkah 5: Susun features mengikut kebergantungan dan nilai

Tidak semua features adalah sama. Daftar keluar tetamu adalah prasyarat untuk kod promo, yang bergantung pada logik penetapan harga. Petakan rantai kebergantungan di peringkat feature sebelum membuat komitmen tertib Sprint.

Proses lima langkah ini boleh digunakan untuk mana-mana domain. Gantikan contoh daftar keluar dengan aliran onboarding, modul pelaporan, atau urutan automasi pemasaran, dan logiknya masih terpakai.

Contoh mengikut pasukan

Fungsi yang berbeza menggunakan hierarki yang sama, tetapi kandungannya kelihatan sangat berbeza.

Perhatikan bahawa setiap kisah pengguna, tanpa mengira pasukan, mengikuti bentuk yang sama: siapa penggunanya, apa yang perlu mereka lakukan, dan mengapa. Klausa "mengapa" inilah yang mengubah tugas menjadi kisah dengan kriteria penerimaan yang nyata.

Amalan terbaik

Gunakan kriteria INVEST untuk kisah. Kisah pengguna yang baik ialah: Bebas (boleh dikerjakan tanpa memerlukan kisah lain), Boleh Dirunding (skop tidak dikunci), Bernilai (menyampaikan sesuatu kepada pengguna sebenar), Boleh Dianggar (pasukan boleh menyaiznya), Kecil (muat dalam satu Sprint), Boleh Diuji (mempunyai kriteria penerimaan). Jalankan mana-mana kisah yang anda tidak pasti melalui senarai semak ini sebelum Sprint.

Potong secara menegak, bukan mendatar. Hirisan mendatar menyampaikan satu lapisan tindanan teknologi (contoh, "bina skema pangkalan data untuk daftar keluar"). Hirisan menegak memotong semua lapisan untuk menyampaikan nilai yang kelihatan kepada pengguna (contoh, "tetamu boleh melihat pengesahan pesanan"). Hirisan menegak membolehkan maklum balas lebih pantas dan pengeluaran lebih awal.

Tetapkan had WIP di peringkat feature. Melayan features sebagai item kerja-dalam-proses, bukan sekadar baldi organisasi, membantu pasukan mengelak memulakan terlalu banyak features secara selari. Rangka Kerja Scrum menggalakkan pengehadan kerja serentak untuk meningkatkan aliran.

Semak semula epics setiap suku tahun, features setiap Sprint, kisah setiap hari. Irama perancangan perlu sepadan dengan skop. Epics tergolong dalam semakan peta jalan suku tahunan. Features tergolong dalam perancangan Sprint. Kisah tergolong dalam Daily Stand-up. Mencampur irama-irama ini adalah sumber biasa beban perancangan.

Hubungkan epics dengan matlamat metodologi Agile. Setiap epic perlu dikaitkan kembali dengan objektif perniagaan (OKR, atau matlamat suku tahunan). Jika sebuah epic tidak dapat dihubungkan dengan matlamat, ia adalah calon untuk Backlog, bukan peta jalan aktif.

Untuk pasukan yang bekerja merentasi beberapa lini produk atau pada skala besar, Scaled Agile Framework (SAFe) menambah dua peringkat lagi di atas epics: keupayaan dan epics portfolio. Dan jika anda menyelesaikan soalan umum tentang cara amalan Scrum terpakai pada prinsip Agile, lihat perbandingan Agile vs Scrum.

Soalan lazim

Adakah feature sama dengan tema?

Tidak. Tema adalah label yang mengumpulkan epics berkaitan untuk komunikasi peta jalan (contohnya, "kebolehpercayaan" atau "pertumbuhan"). Ia tidak mempunyai komitmen penghantaran. Feature adalah keupayaan boleh hantar dalam satu epic. Tema mengatur epics; features menguraikannya.

Berapa banyak kisah pengguna yang perlu ada dalam satu epic?

Tiada nombor tetap, tetapi julat yang boleh dikerjakan ialah 10-30 kisah merentasi semua features dalam satu epic. Kurang daripada 10 menunjukkan epic itu mungkin sebenarnya sebuah feature. Lebih daripada 50 selalunya bermakna epic terlalu luas dan perlu dipecahkan kepada dua epic berasingan dengan matlamat tersendiri.

Adakah epics mempunyai Story Points?

Tidak dalam erti kata tradisional. Story Points digunakan untuk menganggar kerumitan relatif kisah pengguna individu, di mana ketidakpastian cukup kecil untuk berguna. Epics dianggar dalam unit yang lebih besar: saiz baju-T (S/M/L/XL) atau anggaran bilangan Sprint. Menggunakan Story Points di peringkat epic menghasilkan ketepatan palsu.

Bilakah saya perlu memisahkan satu feature kepada dua feature?

Pisahkan apabila: feature meliputi dua perjalanan pengguna yang berbeza, apabila satu bahagian boleh dihantar dan memberikan nilai secara bebas, atau apabila satu bahagian mempunyai masa penghantaran yang jauh lebih lama daripada yang lain. Jika anda menulis penerangan feature dan menggunakan "dan" untuk menghubungkan dua keupayaan yang berbeza, itu adalah isyarat untuk memisahkan.

Bolehkah kisah pengguna wujud di luar epic?

Ya, secara teknikalnya. Item kerja "hutang teknik," "spike," dan bukan feature lain sering ditulis sebagai kisah tanpa epic induk. Tetapi untuk mana-mana kerja berorientasikan pelanggan atau peringkat produk, kisah terapung tanpa feature atau epic induk menjadi item Backlog yatim tanpa konteks yang kelihatan. Pastikan ia dilampirkan kepada induk apabila boleh.

Bacaan berkaitan

• Kisah Pengguna
• Product Backlog
• Backlog Refinement
• Story Points
• Kriteria Penerimaan
• Definition of Done
• Apakah Metodologi Agile
• Agile vs Scrum
• Scaled Agile Framework (SAFe)

Menetapkan hierarki dengan betul adalah pelaburan yang membuahkan hasil setiap Sprint. Pasukan yang bersetuju tentang apa itu epic berbanding feature berbanding kisah berhenti mempertikaikan skop dalam perancangan dan mula menghantar hasil dengan konsisten. Mulakan dengan satu epic, uraikannya melalui proses lima langkah di atas, dan gunakan ia sebagai rujukan bersama pasukan untuk setiap perbualan perancangan yang berikut.