Bagaimana kami memberikan perkiraan waktu yang valid selama Perencanaan Sprint tanpa melakukan desain "terlalu banyak"?

Tim saya semakin cepat dengan Scrum, tetapi kebanyakan dari kita lebih akrab dengan metodologi tangkas "pseudo-". Bagian yang merupakan rintangan terbesar bagi kami adalah menjalankan rapat Perencanaan Sprint yang efisien di mana kami memecah barang-barang jaminan kami menjadi tugas, dan memperkirakan jam. (Saya menggunakan terminologi dari Template Scrum VS2010; permintaan maaf jika saya menggunakan kata yang salah di suatu tempat.)

Ketika kita mencoba untuk mencari tahu berapa lama tugas akan diambil, kita sering jatuh ke dalam perangkap merancang fitur di tingkat kode - tata letak tabel, antarmuka, dll - untuk mencari tahu berapa lama itu akan mengambil .

Saya cukup yakin ini bukan tempat yang tepat untuk melakukan desain semacam itu. Kita harus menjadwalkan tugas untuk rapat desain ini selama sprint. Namun, kami mengalami kesulitan mencari tahu bagaimana cara menghasilkan estimasi yang berarti untuk tugas-tugas tersebut.

Apakah ada kebiasaan / teknik / dll. untuk membuat panggilan penilaian tentang berapa lama fitur akan berlangsung, tanpa mengetahui bagaimana Anda berencana untuk mengimplementasikannya? Jika perkiraan waktu kami akan berubah secara signifikan setelah desain selesai, bagaimana kami dapat menganggarkan dengan benar backlog Sprint kami sebelumnya?

EDIT:

Hanya untuk memperjelas, karena beberapa komentar / jawaban sangat valid tapi saya pikir menjawab pertanyaan yang salah.

Kita tahu bahwa apa yang kita lakukan tidak benar, dan kita harus membangun waktu dalam sprint untuk desain ini. Secara konseptual semua pengembang memahami hal itu. Kami juga membawa anggota tim dengan pengalaman Scrum untuk menjaga kami tetap di jalur jika kami mulai memasuki rumput liar.

Masalahnya adalah bahwa, tanpa melalui proses desain ini, kami merasa sulit untuk memberikan perkiraan waktu yang konkret untuk apa pun. Kami terus-menerus mengatakan hal-hal seperti "baik jika kami mendesainnya dengan cara ini mungkin butuh 8 jam, tetapi jika kami akhirnya harus melakukan ini dengan cara lain, itu akan memakan waktu sekitar 32 tetapi mungkin tidak seburuk setelah kami mulai mencoba menulisnya ... "

Saya juga berasumsi bahwa proses ini akan menjadi lebih baik setelah kita memiliki kecepatan historis untuk bekerja, tetapi banyak teknologi dan pola arsitektur yang kita gunakan adalah hal baru bagi kita. Tetapi jika perkiraan yang berpotensi sangat liar hanyalah bagian alami dari mengadaptasi proses ini maka kita hanya perlu merekondisi diri kita sendiri untuk menerimanya :)

1. Jadwalkan pertemuan "perawatan" berulang di mana Anda memiliki diskusi desain ini. Tim yang saya ikuti memiliki mereka sekali per sprint, pada hari sebelum perencanaan. Tujuannya adalah untuk memiliki desain yang cukup jauh sehingga tim dapat menyepakati perkiraan waktu untuk keseluruhan cerita. Anda dapat mempertimbangkan untuk melakukan pemecahan tugas dalam rapat ini, sehingga perencanaan menjadi murni latihan dalam memutuskan berapa banyak yang akan diambil. Dengan kata lain Anda harus melakukan desain dalam sprint SEBELUM Anda mulai melakukan pekerjaan yang sebenarnya.

2. Pertimbangkan untuk menggunakan poker perencanaan , yaitu poin / unit "upaya" daripada hari kerja untuk memperkirakan tugas. Coba juga untuk memecah cerita sebanyak yang Anda bisa. Semakin lama / semakin kompleks suatu cerita, semakin kecil kemungkinan perkiraan Anda akan akurat.

3. Dalam perencanaan, scrum master harus menjaga perencanaan tetap pada jalurnya dengan menghentikan semua diskusi yang terlalu jauh ke "penyelesaian". Pada saat itu anggota tim diharuskan untuk segera mencapai kesepakatan mengenai estimasi, biasanya memberikan angka batas atas / kasus terburuk. Jauh lebih mudah untuk mengambil lebih banyak pekerjaan jika tugas-tugas berakhir lebih mudah daripada yang Anda rencanakan, daripada berurusan dengan jadwal yang tergelincir karena tugas-tugas yang lebih lama dari yang direncanakan dan cerita-cerita bergulir menjadi beberapa sprint.

4. Bicara tentang bagaimana perkiraan tersebut muncul dalam retrospektif di akhir sprint. Terutama jika ada yang sangat jauh. Apakah tim belajar sesuatu dari bagaimana cerita berjalan versus bagaimana mereka mengharapkannya? Scrum master harus tetap fokus pada perubahan yang dapat ditindaklanjuti yang dapat dilakukan untuk proses desain / estimasi Anda.

Saya pikir masalahnya adalah Anda mencoba memperkirakan waktu. Jangan.

Perkirakan kerumitan. Lihatlah persyaratan, (semoga cerita pengguna) dan nilai seberapa rumit tim berpikir akan mencari cara membangun dan mengujinya, relatif terhadap seberapa rumit persyaratan lain atau cerita pengguna. Terkadang Anda salah, tetapi sering kali Anda akan mendapatkan gagasan yang bagus tentang seberapa sulit sesuatu akan terjadi. Anda juga akan menemukan bahwa item dengan kompleksitas yang hampir sama cenderung membutuhkan upaya yang sama untuk menyelesaikannya.

Jadi, peringkat kompleksitas menjadi "poin cerita" yang terkait dengan cerita pengguna di jaminan produk Anda. Setelah Anda mengerjakan beberapa sprint, Anda akan mendapatkan gagasan tentang berapa banyak poin cerita yang bisa Anda lewati dalam sprint, dan itu adalah kecepatan Anda. Pada saat itu, Anda akan memiliki gagasan yang lebih baik tentang berapa lama setiap item akan memakan waktu.

Saya sangat merekomendasikan Cerita Pengguna Mike Cohn Diterapkan .

Saya tahu pertanyaan Anda secara khusus tentang menghindari desain dalam perencanaan. Tapi ini semacam Masalah XY .

Aku sudah berada di tempatmu sekarang. Daripada memberi Anda sesuatu yang dapat memberikan peningkatan tambahan, saya ingin membantu Anda melompati beberapa negara perantara tersebut.

Berikut adalah tiga hal yang dilakukan tim kami secara khusus terkait dengan perencanaan dan pelaksanaan pekerjaan. Ini telah membantu kami menghindari meronta-ronta desain dan melarikan diri dari perkiraan waktu yang tidak akurat.

Kriteria Penerimaan Automatable

Kisah-kisah kami ditunjukkan oleh sejumlah Kriteria Penerimaan Automatabel . Ini berarti, jika kita harus menulis tes otomatis untuk mengonfirmasi bahwa cerita telah selesai, apa yang akan terjadi?

Misalnya, "Ketika pengguna mengklik 'main' di iPad yang menjalankan iOS 6+, video mulai diputar." Mungkin sulit untuk mengotomatisasi tes ini, tetapi ini merupakan kriteria penerimaan (AC) dari cerita dan menyumbang satu poin.

Kami menggunakan skala Fibonacci, dan kami selalu mengumpulkan. Jadi, jika sebuah cerita memiliki empat kriteria penerimaan otomatis, itu adalah cerita lima poin.

Ukuran poin cerita maksimum kami adalah delapan poin, tetapi kami jarang memilikinya. Jika sebuah cerita memiliki lebih dari lima kriteria penerimaan otomatis, kami menemukan cara untuk membaginya.

Pra-Perawatan

Kami memiliki pertemuan awal pada hari Senin, tetapi pertemuan perawatan kami adalah tempat perencanaan tim terjadi. Sebelum perawatan, anggota tim akan pra-laki-laki cerita dengan menggambarkan hasil dan mengambil bacokan di kriteria penerimaan automatable.

Grooming menghadirkan keahlian tim untuk memahami kisah-kisah yang sudah disiapkan sebelumnya, menemukan persyaratan yang tidak ditentukan, membagi cerita, dll.

Kami kadang-kadang membuat daftar tugas di samping kriteria penerimaan, tetapi ini bukan perkiraan waktu. Kami tidak pernah memperkirakan waktu. Tugas hanyalah pernyataan kerja yang perlu dilakukan untuk mendukung kriteria.

Membatasi Work-in-Progress

Scrum tradisional berupaya membatasi waktu kerja hingga durasi sprint. Kami menemukan bahwa ini secara buatan menyebabkan kami bergegas memenuhi tenggat waktu sprint, membunuh akhir pekan kami karena sprint berakhir pada hari Jumat.

Pendekatan lain adalah membatasi pekerjaan yang sedang berjalan pada waktu tertentu. Kami telah bermigrasi ke yang terakhir dan secara signifikan lebih bahagia karenanya.

Setelah sebuah cerita berpindah dari jaminan yang sedang berjalan, kami mencirikannya sebagai salah satu dari beberapa keadaan:

• Sedang Ditunda - kerja tim tidak dapat terjadi karena kami menunggu beberapa aktivitas tim ekstra
• Dalam Pembangunan - bekerja untuk mencapai kriteria penerimaan
• Tes Kebutuhan - kami yakin kami telah bertemu AC, menunggu orang lain untuk memverifikasi
• Dalam Uji - cerita sedang dievaluasi terhadap AC, bug sedang diatasi
• Siap untuk Menyebarkan - pada kesempatan yang tersedia berikutnya, itu akan ditayangkan

Kami kemudian menggunakan jumlah cerita di setiap negara bagian untuk mengarahkan fokus tim. Misalnya, pengembang mungkin bersedia mengambil cerita baru, tetapi jika kami memiliki banyak cerita Dalam Tes, lebih baik bagi mereka untuk membantu dalam cerita yang ada.

Pertama, ketahuilah bahwa perkiraan akurat tidak mungkin dilakukan dalam keadaan tersebut. Jangan stres jika Anda salah. Namun, Anda masih memerlukan ide kasar untuk merencanakan, dan satu-satunya cara untuk menjelaskan ketidakpastian sepenuhnya adalah dengan menambahkan lebih banyak poin cerita ke perkiraan Anda. Jika Anda tidak tahu apakah itu 5 atau 13, gunakan 13.

Juga bermanfaat untuk memecah cerita sekecil mungkin. Kita sering memiliki cerita penelitian / desain dengan tujuan melakukan pekerjaan yang cukup untuk memiliki ide yang lebih baik tentang bagaimana melakukan fitur tersebut, kemudian fitur cerita itu sendiri masuk ke sprint berikutnya. Pikirkan mengapa ini berhasil. Bahkan jika Anda tidak tahu seberapa sulit sesuatu akan terjadi, Anda biasanya tahu cukup akurat dari pengalaman masa lalu berapa lama untuk mengetahuinya.

Ada dua hal yang bisa Anda lakukan di sini.

Pertama, miliki semacam scrum master yang perannya adalah memantau diskusi dan mengatakan "Hei, kau mendesain lagi" saat itu. Ini lebih sulit daripada yang terlihat, putar orang ke dalamnya hari demi hari dan mulailah membuat semua orang menjadi ahli scrum sehingga siapa pun dapat memanfaatkannya.

Kedua, jika Anda merancang selama perencanaan sprint Anda harus dapat membedakan antara tidak cukup tahu untuk membuat panggilan pada durasi tugas, atau apakah Anda hanya merancang karena itu lebih menyenangkan.

Sekali lagi, master scrum harus menendang di sini dan memberi tahu Anda untuk menahan barang sampai Anda cukup tahu untuk menjadwalkannya, atau membuat Anda berhenti mendesain dan menjawab pertanyaan awal (Berapa lama waktu yang diperlukan).

Jadi, jika Anda melakukan perencanaan sprint, masuk akal untuk memiliki sponsor bisnis di sana untuk memeriksa simpanan Anda dan memprioritaskan hal-hal yang ingin mereka lihat dilakukan terlebih dahulu. Jika Anda melakukannya, Anda akan merasa lebih sulit untuk mendesain selama sesi karena mereka akan gelisah dan akhirnya tidak mau datang.

Kami telah beroperasi berdasarkan perkiraan cerita 'dingin' selama perencanaan sprint dengan hanya beberapa diskusi terbatas. Perkiraan ini benar-benar sangat tidak akurat meskipun pembentukan tim dengan fokus yang cukup sempit ... terutama karena adanya banyak kode warisan yang tidak terdokumentasi dan tidak diomentari tanpa ada gagasan nyata tentang apa yang seharusnya terjadi dan staf yang sebagian besar telah berubah sejak aslinya ditulis.

Apa yang kami coba sekarang adalah meluangkan waktu sebelum merencanakan penyelidikan setiap cerita - dan di sini hanya satu dev akan menyelidiki satu cerita ... Kami berharap bahwa ini berarti bahwa dev yang menyelidiki akan dapat memberikan beberapa klarifikasi dan wawasan kepada membantu estimasi. Sejauh ini telah membantu pada kesempatan yang telah dicoba.

Saya belum yakin bahwa penyelidikan tambahan benar-benar membuat perkiraan cukup akurat untuk membenarkan biaya tetapi kami akan mencobanya untuk melihat beberapa sprint.