Pernahkah Anda benar-benar menggigit lebih dari yang bisa Anda kunyah? Ini bukan perasaan yang menyenangkan. Dan juga bukan backlog yang kelebihan beban. Seperti steak yang juicy, sprint backlog yang sehat paling baik jika dikonsumsi dalam porsi kecil, atau cerita pengguna. (Dan, jika Anda memiliki sekumpulan cerita besar, tindakan terbaik Anda adalah anggur merah yang baik.)
Tidak hanya cerita pengguna yang lebih kecil membuatnya lebih mudah untuk mencerna (ahem) sprint, tetapi percakapan yang dihasilkan saat memecahnya memfasilitasi pemahaman yang lebih dalam tentang pekerjaan tersebut. Saat Anda dihadapkan dengan ’96er lama, berikut adalah beberapa tips untuk membantu Anda membersihkan piring Anda.
Temukan batasan Anda.
Lihatlah kinerja historis tim Anda pada cerita berukuran berbeda. Anda akan melihat titik istirahat di mana cerita menjadi berat atau menggelembung secara tidak terduga. Ketika cerita menyebabkan sprint bloat, itu kemungkinan merupakan gejala kompleksitas yang tidak terhitung. Jika cerita 13 poin itu selalu berakhir dengan menyeret beberapa sprint, inilah saatnya untuk menyetujui bahwa cerita Anda harus berukuran 8 atau lebih rendah. Membatasi ukuran cerita memberi tim Anda rambu ketika mereka perlu menggali lebih dalam cerita sebelum siap sprint.
Dapatkan epik.
Terkadang sepertinya cerita besar hanya akan menambah nilai bisnis saat diimplementasikan sepenuhnya. Ketika dihadapkan dengan jenis fitur ini, tim, seperti banyak rapper yang sudah tua, berjuang untuk memecahkannya. Untuk membantu mereka mendapatkan perspektif, pertimbangkan untuk memposisikan cerita besar sebagai epik, dan lacak nilai bisnis fitur ke epik sebagai gantinya. Jadi serangkaian cerita yang lebih kecil akan secara bertahap memenuhi epik, memungkinkan kemajuan berkelanjutan dalam skala cerita kecil sambil juga membangun nilai dengan cara yang nyata.
Tarik keluar buku tata bahasa Anda.
Temukan kata sifat dalam cerita pengguna Anda. Apakah Anda melihat kata-kata “mudah”, “fleksibel” atau “cepat?” Itu adalah tanda-tanda pasti bahwa cerita ini perlu memiliki parameter yang lebih pasti. Sekarang cari konjungsi itu; “dan” dan “atau” adalah indikator yang baik bahwa fungsionalitas Anda adalah untuk lebih dari satu fitur. Ini juga merupakan pembuka percakapan hebat lainnya yang akan mengarah ke cerita yang lebih kecil, semoga dengan diagram kalimat yang sangat sedikit diperlukan. Diagram kalimat = lebih banyak anggur.
Ambil jalan yang kurang dipilih. Dan yang lainnya juga.
Saat memeriksa sebuah cerita, biasakan untuk mengidentifikasi jalur bahagia dan jalur tidak bahagia melalui alur cerita. Misalnya, pertimbangkan kisah pengguna berikut:
Sebagai anggota forum, saya harus dapat masuk agar dapat berpartisipasi dalam komunitas forum.
Saatnya untuk mengenakan topi QA Anda dan memikirkan beberapa skenario kasus uji. Pertama, identifikasi jalan bahagia:
Ketika saya memasukkan nama pengguna dan kata sandi yang benar, saya berhasil masuk dan saya dibawa ke dasbor anggota saya.
Sekarang tiba bagian menyenangkan. Mari kita lepas kacamata berwarna mawar (tetap pakai topi QA, terlihat keren dengan kaos Star Wars Anda) dan pertimbangkan jalan tidak bahagia yang bisa diambil pengguna:
Ketika saya memasukkan kombinasi nama pengguna dan kata sandi yang tidak valid, saya melihat kesalahan validasi.
Ketika saya memasukkan kombinasi nama pengguna dan kata sandi yang tidak valid lebih dari tiga kali, akun saya terkunci selama 24 jam.
Jika saya tidak dapat mengingat nama pengguna saya, saya dapat mengeklik tautan untuk memulihkan nama pengguna saya.
Jika saya tidak dapat mengingat kata sandi saya, saya dapat mengklik tautan untuk mengatur ulang kata sandi saya.
Saat Anda terus memikirkan cara agar fitur tersebut dapat gagal, Anda akan menemukan jalur yang matang untuk menjadi cerita mereka sendiri. Dalam daftar di atas, jalan tidak bahagia mana yang menurut Anda cocok untuk cerita yang terpisah? Jika Anda masih tidak yakin, lihat tip berikutnya.
Dapat diuji adalah yang terbaik
Jika Anda kesulitan memecah sebuah cerita menjadi potongan-potongan kecil yang bermakna, pertimbangkan huruf terakhir dalam akronim INVEST: Dapat diuji. Saat tim dihadapkan dengan fitur besar yang sulit diuraikan, minta mereka untuk memecahnya menjadi unit yang dapat diuji. Ini akan memberi mereka cara baru untuk melihat karya dan secara alami akan mengarah ke cerita yang lebih kecil.
Jika Anda tidak tahu, sekarang Anda tahu
Tip terakhir: merangkul yang tidak diketahui. Perencanaan Poker® dan penyempurnaan backlog cenderung membuat tim merasa harus pergi dengan poin upaya di buku. Sangat penting untuk menumbuhkan lingkungan di mana tim Anda merasa nyaman untuk mengakui ketika mereka tidak tahu berapa ukuran ceritanya. “Saya tidak tahu” bisa menjadi langkah pertama untuk mengukur cerita dengan benar yang membawa potensi jebakan dan hal yang tidak diketahui.
Lapar untuk lebih banyak tips tentang sprint backlog dan perencanaan? Lihat lebih lanjut dari planningpoker.com.
Kredit Foto
