Halo, Habr! Saya mempersembahkan kepada Anda terjemahan artikel
"Mengapa Saya Tidak Menggunakan Poin Cerita untuk Perencanaan Sprint" oleh Mike Cohn.
Seperti yang dijelaskan dalam Agile Estimating and Planning, saya adalah penggemar berat poin cerita untuk mengevaluasi simpanan produk. Namun, saya juga merekomendasikan untuk mengevaluasi sprint backlog dalam hitungan jam daripada poin cerita. Mengapa kontradiksi ini tampak jelas? Sebelumnya saya menulis tentang alasannya. Saya merekomendasikan menggunakan unit pengukuran yang berbeda (poin dan jam) untuk jaminan simpanan yang berbeda.
Tetapi saya sering ditanya pertanyaan terkait, yang ingin saya tanyakan di sini:
Saya ingin tahu mengapa Anda tidak menggunakan poin cerita untuk perencanaan sprint. Saya pikir titik pengukuran kecepatan dalam poin cerita adalah, sebagian, untuk menentukan berapa banyak yang dapat kita ambil (atau perbaiki) dalam sprint. Apakah Anda hanya menggunakan poin cerita untuk perencanaan jangka panjang (mis. Perencanaan rilis)?Saya tidak menggunakan poin cerita untuk perencanaan sprint karena poin cerita adalah ukuran jangka panjang yang berguna. Tetapi poin tidak berguna dalam jangka pendek.
Akan pantas bagi tim untuk mengatakan: "Kami memiliki kecepatan rata-rata 20 poin cerita, dan kami memiliki 6 sprint yang tersisa, jadi kami akan menyelesaikan sekitar 120 poin cerita dalam enam sprint ini."
Tidak pantas bagi tim untuk mengatakan: "Kami memiliki kecepatan rata-rata 20 poin poin, jadi kami akan selesai dalam sprint berikutnya." Ini tidak bekerja
Misalkan tim bola basket ada di tengah musimnya. Hingga saat ini, mereka telah memainkan 41 pertandingan dan mencetak rata-rata 98 poin per pertandingan. Adalah tepat untuk mengatakan: "Mungkin, kami akan mencetak rata-rata 98 poin per pertandingan di sisa musim ini." Tapi mereka seharusnya tidak mengatakan sebelum pertandingan tertentu: "Kami memiliki rata-rata 98, jadi kami akan mengambil 98 hari ini." Itulah mengapa saya mengatakan bahwa kecepatan adalah alat prediksi jangka panjang yang bermanfaat, tetapi bukan alat prediksi jangka pendek yang bermanfaat.
Kecepatan akan bervariasi dari sprint ke sprint.
Itu sebabnya saya ingin tim merencanakan sprint mereka dengan melihat tumpukan produk, memilih salah satu hal paling penting yang bisa mereka lakukan, memecah elemen / cerita pengguna dari tumpukan produk ini menjadi tugas dan mengevaluasi tugas, bertanya pada diri sendiri apakah mereka dapat mengambil komitmen untuk merilis item jaminan produk dan kemudian diulang sampai diisi. Tidak ada diskusi tentang poin cerita. Tidak ada diskusi tentang kecepatan. Ini hanya masalah kewajiban, dan kami memutuskan berapa banyak yang dapat kami penuhi dengan memecah poin tumpukan produk menjadi tugas dan mengevaluasi mereka.
Ketika tim selesai merencanakan sprint dengan cara ini, ada kemungkinan bahwa jumlah poin cerita yang mereka kejar harus dekat dengan nilai rata-rata mereka, tetapi itu akan berubah.
Juga benar bahwa tim akan melakukan kira-kira jumlah jam yang sama dari satu sprint ke sprint berikutnya. Saya menggunakan istilah "kapasitas" untuk merujuk pada jumlah jam ini karena kecepatan disediakan untuk merujuk pada pengukuran volume pekerjaan yang direncanakan atau diselesaikan, seperti yang ditunjukkan dalam unit yang digunakan untuk mengevaluasi jaminan simpanan produk (yang saya sarankan menggunakan poin cerita )
Tentang Pengarang: Mike Cohn adalah salah satu penulis metodologi pengembangan perangkat lunak Scrum. Dia adalah salah satu pendiri Agile Alliance dan Scrum Alliance. Ia berspesialisasi dalam membantu perusahaan menerapkan dan meningkatkan penggunaan proses dan metode lincah untuk menciptakan tim berkinerja tinggi.
Referensi:
Agile Estimating and Planning , Mike Cohn, 2005.
NB. Apakah Anda menilai sprint backlog dalam jam atau poin cerita?