Bagaimana menangani 50% lebih buruk dari sprint rata-rata?

Jika saya memahami Scrum dengan benar, ini adalah cara saya menentukan pekerjaan yang dapat dilakukan tim saya di sprint berikutnya:

1. Saya rata-rata jumlah poin yang diselesaikan untuk beberapa sprint terakhir.

2. Kuantitas ini adalah kecepatan rata-rata kami. Sprint berikutnya, kami mengambil banyak poin cerita.

Ini adalah rata - rata , jadi jika sejarah berulang, sprint ini 50% kemungkinannya kita mengambil terlalu sedikit poin cerita, dan 50% kemungkinan bahwa kita mengambil terlalu banyak poin cerita.

Dalam 50% kasus kami telah mengambil terlalu banyak poin cerita yang kami bisa:

• Gagal menyelesaikan sprint. Ini berarti kami akan gagal memenuhi komitmen sprint kami separuh waktu.

• Bekerja ekstra untuk mengejar ketinggalan. Masalahnya adalah ratchet ini hanya satu arah. Kami akan menyelesaikan sprint, dan jumlah poin cerita yang diselesaikan akan mencerminkan hal itu. Karena kita selalu selesai, dari waktu ke waktu, rata-rata kita akan cenderung naik ke titik di mana kita selalu mencapai sejumlah besar poin cerita dan tetap terlambat.

Apakah pemahaman saya tentang kecepatan rata-rata dan komitmen sprint sudah benar?

Jika demikian, apa yang harus kita lakukan untuk 50% sprint di mana kita berada di belakang rata-rata?

Jika tidak, apa yang salah dengan saya?

Apakah pemahaman saya tentang kecepatan rata-rata dan komitmen sprint sudah benar?

Ya, Anda memiliki intinya.

Jika tidak, apa yang salah dengan saya?

Hal yang Anda abaikan adalah bahwa poin cerita adalah hal yang harus Anda lakukan . Hampir tidak mungkin bagi semua orang untuk mengerjakan cerita sampai akhir sprint. Jika Anda melakukan hal-hal yang benar, sebagian besar pengembang Anda akan "menganggur" selama beberapa hari saat cerita sedang diuji (dan penguji Anda di tengah sprint karena pengembangan sedang berjalan lancar).

Saya memberi tanda kutip karena pengembang Anda tidak duduk menonton video kucing, mereka memperbaiki bug, memoles beberapa tes kode / unit, menambahkan beberapa dokumentasi di sekitar proses, memikirkan desain untuk cerita di backlog atau salah satu lusinan hal berguna lainnya yang dapat dimanfaatkan oleh tim pengembangan tetapi tidak cocok dengan cerita.

Jadi, sementara Anda akan menebak 50% dari waktu dan 50% di bawah perkiraan, itu tidak berarti Anda akan gagal dalam sprint atau harus bekerja lembur . Ini berarti bahwa Anda tidak akan memiliki cukup banyak waktu untuk melakukan pekerjaan lain-lain ini (kecuali jika Anda benar-benar kehilangan perkiraan Anda). Tapi itu bukan masalah besar, karena pekerjaan lain-lain tidak sensitif terhadap waktu, dan hal-hal akan terjadi dalam jangka panjang.

Apakah pemahaman saya tentang kecepatan rata-rata dan komitmen sprint sudah benar?

Sayangnya, Anda telah salah informasi tentang beberapa hal mengenai Perencanaan Sprint di Scrum. Pertama, Tim Pengembangan (DT) adalah

... terstruktur dan diberdayakan oleh organisasi untuk mengatur dan mengelola pekerjaan mereka sendiri. - Panduan Scrum

Kata untuk ini adalah mengatur diri sendiri. Ini termasuk pekerjaan memperkirakan pekerjaan yang akan dilakukan dalam Sprint yang diberikan. DT tidak diberi tahu apa yang akan bekerja pada setiap sprint, agak diberdayakan untuk memilih pekerjaannya sendiri. DT mungkin memerlukan informasi seperti kecepatan historis, Product Backlog yang disempurnakan dengan baik, dan kapasitas DT Sprint berikutnya untuk membuat perkiraan. Pada akhirnya, penentuan DT tentang apa yang dapat dan tidak dapat dicapai dalam Sprint yang harus berlaku dalam perkiraan mereka; mereka tidak boleh diberi tahu berapa banyak pekerjaan yang akan mereka lakukan.

Perhatikan juga, ramalan dan bukan komitmen. Kata-c telah dihapus dari Panduan Scrum karena digunakan untuk menyalahgunakan Tim Pengembangan. Prakiraan adalah istilah yang disukai.

Mengenai kemungkinan kehilangan ramalan Sprint pada akhir rendah atau tinggi, saya tidak melihat itu sebagai hal yang penting. Pada titik tertentu, lebih banyak analisis tidak menghasilkan akurasi yang lebih baik dan saya pikir kita melampaui titik itu sekarang.

Selain itu, Sprint hanya dapat "Dibatalkan;" itu tidak pernah bisa gagal. Sprint dibatalkan hanya ketika tujuan sprint menjadi benar-benar usang dan tidak relevan. Ini sangat jarang terjadi. Jika ramalan salah, Anda tetap tenang dan teruskan. Sudahkah Anda retrospektif. Sprint Selanjutnya, perkiraan Anda akan lebih baik :).

Pertama, kecepatan Anda berasal dari sprint Anda sebelumnya, atau kadang-kadang dari rata-rata beberapa Sprint terbaru (Cuaca Kemarin), dan bukan rata-rata dari semua sprint sebelumnya. Tentu saja, jika Anda tidak memiliki data historis dari tim atau perusahaan Anda, Anda harus menghasilkan nilai yang masuk akal untuk sprint pertama Anda. Pada sprint kedua Anda, Anda memasukkan poin cerita yang sudah selesai ke dalam sprint. Jika Anda membuat grafiknya, Anda dapat melihat variasi pada beberapa sprint pertama (misalnya, 17 di sprint pertama, 22 di sprint kedua, 26 di sprint ketiga, 24 di sprint keempat). Itu diharapkan saat Anda menormalkan kerja tim Anda dan proses estimasi, bersama dengan mendapatkan pemahaman yang lebih baik tentang proyek (teknologi, domain).

Itu bukan untuk mengatakan bahwa Anda tidak menyesuaikan. Misalnya, jika Anda memiliki satu minggu yang merupakan hari libur, pastikan untuk memperhitungkan hari libur di mana pekerjaan ditutup. Jika Anda tahu bahwa anggota tim sedang berlibur, rencanakan lebih sedikit orang yang bekerja. Tentu saja, kejadian yang tidak direncanakan juga terjadi, tetapi Anda dapat menjelaskannya dalam retrospektif sprint dan Anda dapat memutuskan bagaimana hal itu memengaruhi jumlah poin cerita yang Anda bawa ke sprint berikutnya.

Sejauh apa yang harus dilakukan, "gagal menyelesaikan sprint" berbeda dari "kami tidak menyelesaikan semua cerita". Bagi saya, kegagalan sprint berarti bahwa Anda tidak menghasilkan produk yang berpotensi dapat dikirim pada akhirnya - tidak ada cerita Anda yang lengkap, Anda tidak memiliki bangunan, Anda tidak dapat menunjukkan nilai tambah kepada pelanggan atau pengguna.

Apa pun yang Anda lakukan, Anda tidak boleh bekerja lembur atau berlebihan dari waktu ke waktu. Ini disebut langkah berkelanjutan ( Agile Alliance , Scrum Alliance ).

Indikator bahwa mungkin ada masalah adalah jika:

• Tim Anda tidak bekerja dengan kecepatan yang berkelanjutan. Anda perlu bekerja lembur untuk menyelesaikan poin cerita yang direncanakan untuk sprint. Buat sprint Anda lebih kecil untuk diselesaikan tepat waktu tanpa tekanan tambahan.
• Kecepatan Anda tidak menjadi normal seiring waktu. Tidak ada yang mengharapkan kecepatan untuk tidak pernah berubah, tetapi jika Anda melihat paku atau ayunan, hadapi dengan yang ada di retrospektif lari Anda. Cari tahu apa penyebabnya dan alamat akar masalahnya.

Metodologi tangkas bervariasi dari perusahaan ke perusahaan, dalam satu implementasi itu bisa sangat berbeda dari yang lain. Saya telah bekerja di bawah Agile dengan dua perusahaan. Di perusahaan pertama saya berada di mereka mengambil metrik mereka cukup serius, di perusahaan kedua tidak benar-benar sama sekali. Jadi untuk semua yang Anda tahu tidak ada yang memperhatikan metrik Anda.

Semua yang dikatakan, sepertinya Anda khawatir tidak memenuhi tujuan sprint Anda, atau apa yang terjadi ketika Anda memiliki perkiraan yang tidak akurat. Saya pikir jenis kekhawatiran dan pandangan seperti ini biasa terjadi, tetapi itu tidak terlalu penting. Agile, di atas segalanya, adalah sistem pengembangan perangkat lunak yang melakukan beberapa hal:

1. Membuat pengembang terus bergerak
2. Meningkatkan transparansi
3. Memungkinkan refleksi dan peningkatan proses bertahap

Pada akhirnya, jika Anda salah memperkirakan sprint, atau gagal sprint, itu bukan masalah besar. Orang-orang yang berada di atas tim Anda di perusahaan Anda cenderung lebih khawatir bahwa tim Anda bergerak secara konsisten, dan proyek sedang diselesaikan secara logis.

Sebagai individu di bawah Agile, Anda harus paling peduli dengan seberapa banyak pekerjaan yang Anda selesaikan secara efektif mengacu pada anggota tim Anda yang lain. Jika Anda baru, Anda tidak dapat diharapkan menjadi terlalu produktif, tetapi pada titik tertentu dalam masa kerja Anda, Anda harus setara dengan setidaknya beberapa tim Anda. Jika Anda tidak menghasilkan pekerjaan, Anda tidak benar-benar melakukan pekerjaan Anda.

Apakah pemahaman saya tentang kecepatan rata-rata dan komitmen sprint sudah benar?

Kecepatan rata-rata Anda tepat. Dalam pengalaman saya ini sangat berguna untuk estimasi penyelesaian jangka panjang - dengan asumsi Anda memiliki banyak simpanan; tetapi tidak berguna untuk komitmen perencanaan sprint.

Proses yang saya lihat diikuti untuk perencanaan sprint adalah menarik cerita dari bagian atas tumpukan dan membiarkan tim memutuskan apakah mereka dapat mencapainya. Tim telah memutuskan ini berdasarkan perasaan usus, memecah menjadi tugas 1/2 hari, tekanan dari Pemilik Produk, penyelarasan dengan tujuan sprint, tebakan terbaik (berdasarkan kecepatan) atau kombinasi dari semuanya.

Kadang-kadang Pemilik Produk telah diizinkan untuk melewatkan beberapa item sehingga lebih banyak yang dapat ditambahkan.

Terkadang tim dan pemilik produk menyetujui item peregangan untuk melanjutkan.

Ini adalah pertanyaan yang sangat bagus dan sangat penting bagi tim untuk ditingkatkan. Topiknya menipu dan disalahpahami secara luas. Tujuan asli dari pengarahan cerita adalah untuk menemukan metode yang cepat dan akurat untuk memperkirakan Level Upaya (LOE) yang diperlukan untuk melengkapi fungsionalitas yang didefinisikan dalam cerita. Tujuan keseluruhan: memberi tim metode PERAMALAN atau memperkirakan berapa lama waktu yang dibutuhkan untuk menyelesaikan upaya (seperti proyek). Pemahaman Anda tentang Velocity benar: ini adalah poin RATA-RATA per Sprint selesai (benar-benar SELESAI). Jadi, jika Anda memiliki proyek untuk dikirim, dan itu adalah 250 poin, dan tim Anda rata-rata 25 poin per sprint, proyek akan mengambil sekitar 10 sprint, plus atau minus beberapa waktu buffer.

Beberapa tokoh, seperti Ken Schwaber, menyarankan bahwa kecepatan dan titik hanya digunakan untuk peramalan jangka menengah hingga jangka panjang. Mereka menyarankan menggunakan jam kerja sebagai "pemeriksaan kewarasan" kedua tentang apa yang sebenarnya bisa dilakukan dalam sprint. Jadi jumlah poin dalam setiap sprint dapat bervariasi tergantung pada kapasitas. Yang lain (termasuk saya), percaya bahwa tim yang matang akan menyesuaikan diri dengan pola ukuran yang sangat konsisten yang dapat secara akurat memprediksi kapasitas, dan pada akhirnya jam kerja menjadi beban tambahan yang tidak berguna. (Sangat penting untuk melakukan bagi tim baru untuk setidaknya 6 hingga 12 sprint, IMHO, sampai pemahaman tim tentang poin dan ukuran cerita akurat.)

Kesalahan kecil pertama Anda adalah Anda mengatakan bahwa tim harus mengetahui kecepatan dan membawa banyak poin cerita. Sebenarnya, pelatih mendorong tim untuk mengurangi 10% hingga 20% dan berkomitmen * ke level itu. Jadi, jika tim Anda cenderung menyelesaikan 25 poin per sprint, jangan isi sprint hingga 25 poin, tetapi berhenti di 20 hingga 22 poin. Ingat: adalah HALUS untuk membawa cerita ketika pekerjaan lain selesai. Jadi, Anda mungkin "berkomitmen" ke 22 poin dan menyelesaikan 28. Itu bagus. Hanya berhati-hati untuk tidak mendorong tim untuk "karung pasir" dan terus-menerus di bawah komit. Tidak ada yang salah dengan peregangan untuk melihat apakah kita bisa berbuat lebih banyak.

Sekarang, ke poin Anda tentang perbedaan antara sprint. Ini adalah pola yang sangat umum (tetapi BUKAN OPTIMAL) untuk melihat tim yang menyelesaikan 20 poin satu sprint, lalu 50, lalu 22, lalu 45, lalu 15, kemudian 60. Jika Anda menghitung deviasinya, ini mungkin menunjukkan perubahan 50% hingga 100% sprint setelah sprint. Mengapa tim menyelesaikan hanya 15 poin dalam satu sprint, dan kemudian 60 di berikutnya?

Ini mungkin berarti bahwa tim benar-benar tidak tahu apa yang bisa mereka lakukan. (Hei, kita menyelesaikan sprint terakhir 50 poin, kita bisa melakukannya lagi sprint ini).

ATAU, ini mungkin menunjukkan bahwa pemilik produk memaksa tim untuk melakukan terlalu banyak komitmen, atau menambah pekerjaan setelah sprint dimulai, dll. Ini hanya beberapa POLA ANTI yang dapat menyebabkan ayunan liar ini di titik yang telah diselesaikan.

Ukuran prediktabilitas ini adalah yang penting bagi master scrum untuk diperhatikan dan dibawa ke perhatian tim. Seringkali, alasan mereka menyelesaikan beberapa poin dalam satu sprint, dan kemudian banyak poin dalam sprint berikutnya adalah apa yang saya sebut sebagai "GELOMBANG GELOMBANG KERJA KERJA YANG TIDAK DIKENAL". Berikut adalah pola yang sangat umum:

Pemilik produk berada di bawah tekanan untuk memenuhi tanggal. Jadi tim merasa perlu mencoba menyelesaikan banyak pekerjaan. Mereka memulai sebagai tim baru, dan tidak yakin apa yang sebenarnya bisa mereka lakukan.

Jadi sprint 1, mereka merencanakan sprint dan karena mereka berada dalam fase Forming, tidak dapat menyelesaikan semua pekerjaan. Bahkan, mereka memiliki pekerjaan yang lebih tidak lengkap daripada pekerjaan yang dilakukan. Pekerjaan yang tidak lengkap DIMULAI tetapi tidak berhasil. Itu dipindahkan ke sprint berikutnya, dan kali ini mereka lebih banyak melakukan pekerjaan daripada tidak lengkap. Menjelang sprint berikutnya, beban besar pekerjaan tidak lengkap itu jatuh ke SELESAI dan kepercayaan diri tim melonjak.

Pemilik produk sangat bersemangat sehingga mereka menambah beban lagi. Pada akhir sprint ini, mereka memiliki sejumlah besar pekerjaan yang tidak lengkap, dan jumlah yang mengecewakan dari pekerjaan DILAKUKAN.

Di sini Anda mulai melihat GELOMBANG Selesai vs Sprint bolak-balik tidak lengkap. Jika tim tidak menyadari apa yang terjadi, pola ini dapat berlanjut selama berbulan-bulan. Tapi rata-rata, mereka menyelesaikan sekitar 24 poin per sprint. Jadi apa yang terjadi ketika mereka berhenti melakukan komitmen berlebihan?

Anda akan mencatat bahwa mereka MASIH menyelesaikan 24 hingga 26 poin, tetapi pekerjaan carry-over berkurang. Sekarang, alih-alih kewalahan mencoba menyelesaikan sejumlah pekerjaan yang mustahil, yang juga menghancurkan moral tim, tim dapat mulai meningkatkan proses mereka.

Seiring waktu, kecepatan akan mulai meningkat, tanpa ayunan besar dalam pekerjaan Selesai-vs-Tidak Lengkap.

Jika Anda tidak memberi waktu "kendur" pada tim, mereka tidak akan pernah punya waktu untuk melakukan pekerjaan yang akan membuat mereka lebih ramping, lebih cepat, lebih baik. Dev-Ops, misalnya, tidak bisa terjadi. Tes Otomasi - Siapa yang punya waktu untuk itu !? Tapi ini justru hal-hal yang perlu dikerjakan tim agar mereka dapat meningkatkan kecepatan.