PBI vs Kisah Pengguna

Baru-baru ini sebuah item telah ditambahkan ke Product Backlog oleh pemilik produk yang mengatakan "Ketika saya pergi ke halaman login dari halaman x, saya melihat kesalahan. Saya ingin kesalahan itu dihapus".

Bagiku ini bukan kasus penggunaan, dan seharusnya tidak menjadi PBI (Product Backlog Item). Namun, ketika saya membahasnya, scrum master memberi tahu saya bahwa cerita pengguna bukan PBI dan, PBI bisa berupa laporan bug, tugas, kisah pengguna, apa pun, dan secara harfiah setiap item yang harus ditangani terlebih dahulu.

Saya tidak yakin tentang ini. Saya juga tidak dapat menemukan definisi PBI yang baik di web . Jadi, pertanyaan saya adalah, hal - hal apa yang bisa masuk ke Product Backlog sebagai item? Apakah item backlog produk memetakan ke cerita pengguna? Apakah mereka sama?

Apakah item backlog produk memetakan ke cerita pengguna? Apakah mereka sama?

Tidak harus, tetapi secara umum, mereka melakukannya. Seperti kata master scrum Anda, hal-hal lain juga bisa menjadi item jaminan simpanan produk. Namun, itu tergantung pada cara kerja SCRUM Anda . Beberapa tim memiliki backlog bug terpisah yang dipertimbangkan untuk sprint juga, sementara yang lain menyimpannya di backlog produk.

Dua log terpisah mempersulit pemilik produk untuk memprioritaskan tugas, karena sekarang dua log harus dipertimbangkan untuk sprint berikutnya. Tetapi mereka memang menawarkan pengawasan yang lebih baik dan keduanya dapat diprioritaskan secara terpisah.

Jadi, pertanyaan saya adalah, hal-hal apa yang bisa masuk ke Product Backlog sebagai item?

Ini bisa berupa apa saja yang merupakan bagian dari visi produk dan perjalanan menuju produk yang ingin Anda ciptakan. Sebagian besar berisi persyaratan (cerita pengguna) tetapi juga dapat berisi tindakan atau hal-hal teknis yang tidak secara langsung milik produk (mis. "Beli server baru untuk tim pengembang", "Buat iklan untuk produk"). Tunggakan harus menghindari perincian yang tidak perlu dan jangan mencoba mengatur hal-hal teknis secara mikro. Tumpukan produk dapat berisi apa pun yang memberikan nilai pada produk.

Tidak ada satu Scrum sejati. Terkadang backlog yang terpisah adalah cara yang lebih baik untuk mengelola produk, terkadang mereka hanya menghalangi. Cari tahu apa yang paling cocok untuk Anda.

Saat mengerjakan bug, kami menambahkannya ke tumpukan dan menyebutnya cerita bug . Dengan menambahkan perbaikan bug pada backlog dengan cara ini, jelas bukan hanya perbaikan bug. Kami dapat menambahkan tugas lain untuk memastikan pengujian otomatis ditulis dan verifikasi dilakukan. Ini juga membuatnya lebih eksplisit bahwa DoD harus diikuti.

Kami tidak pernah menggunakan istilah PBI (meskipun alat jaminan simpanan kami menyebutnya demikian), itu selalu merupakan cerita pengguna, cerita bug, atau hanya sekadar cerita .

Ini terutama hanya pilihan terminologi tim Anda dan selama Anda semua jelas apa yang sebenarnya tidak penting.

Semua jawaban di atas gagal untuk referensi dokumen sumber otoritatif untuk kerangka kerja Scrum: Panduan Scrum .

Product Backlog

Ada bagian yang menggambarkan Product Backlog dan barang-barang, sering disebut sebagai PBI, yang terkandung di dalamnya.

Product Backlog mencantumkan semua fitur, fungsi, persyaratan, peningkatan, dan perbaikan yang merupakan perubahan yang harus dilakukan terhadap produk dalam rilis mendatang.

Tetapi tidak diperbaiki seperti rencana proyek.

Product Backlog berkembang sebagai produk dan lingkungan di mana ia akan digunakan berkembang. Product Backlog bersifat dinamis; itu terus berubah untuk mengidentifikasi produk apa yang harus sesuai, kompetitif, dan bermanfaat.

Kisah Pengguna

Istilah cerita pengguna tidak pernah muncul dalam The Scrum Guide karena

ini adalah kerangka kerja di mana Anda dapat menggunakan berbagai proses dan teknik.

Menggunakan cerita pengguna hanyalah salah satu teknik yang memungkinkan untuk merekam PBI.

TAMBAHAN: Meskipun umum untuk melihat format "As a, I want, So that", itu bisa berlawanan dengan maksud aslinya . Format yang merepotkan ini juga telah ditangani di Agile 2017 .

@ Falcon telah menjelaskannya dengan baik. Satu halaman yang memiliki definisi formal adalah: http://en.wikipedia.org/wiki/Scrum_(development)#Product_backlog Apa yang telah Anda gambarkan tidak boleh ditempatkan dalam jaminan produk sesuai dengan diskripsi tersebut setidaknya.

Ada kesalahpahaman umum bahwa hanya cerita pengguna yang diperbolehkan dalam Product Backlog. Sebaliknya, Scrum netral pada teknik persyaratan. Sebagai Scrum Primer menyatakan,

Product Backlog Item diartikulasikan dengan cara apa pun yang jelas dan berkelanjutan. Berlawanan dengan kesalahpahaman populer, Product Backlog tidak mengandung "cerita pengguna"; itu hanya berisi item. Barang-barang tersebut dapat diekspresikan sebagai cerita pengguna, kasus penggunaan, atau pendekatan persyaratan lain yang menurut kelompok berguna. Tapi apa pun pendekatannya, sebagian besar barang harus fokus pada memberikan nilai kepada pelanggan. *

• Spesifikasi perubahan dan penambahan yang berbeda pada produk, disebut Product Backlog Items (PBIs), yang bersama-sama membentuk Product Backlog.
• Setiap PBI menjelaskan sesuatu yang dapat dikembangkan dan disampaikan oleh Pengembang untuk menambah nilai bagi pemangku kepentingan terkait saat Selesai (lihat Definisi Selesai).
• Stakeholder yang paling umum adalah pasar, atau perwakilannya - Pemilik Produk.
• Namun, PBI dapat menggambarkan pekerjaan yang mengurangi biaya bagi perusahaan atau mengurangi upaya untuk Tim Pengembangan, atau alat yang membantu Tim Pemilik Produk melakukan pekerjaannya dengan lebih baik.
• PBI dapat menggambarkan apa pun yang memiliki nilai potensial bagi pemangku kepentingan.

Cerita (pengguna) adalah format standar yang bermanfaat untuk item jaminan simpanan. Alasan di baliknya adalah "jika tidak ada yang peduli, jangan buang waktu". Ini juga memungkinkan PO untuk menilai urgensi item karena menentukan siapa Anda akan melakukannya dan seberapa buruk itu.

Dalam kasus Anda, bug dapat dengan mudah diformat sebagai cerita.

• Sebagai pengguna
• Saya ingin dapat masuk dari halaman X (dan bukannya mendapatkan kesalahan)
• jadi saya tidak akan kehilangan waktu, jengkel dan kehilangan kepercayaan pada produk

Kedengarannya itu sepadan dengan usaha.