Dalam standup Scrum, haruskah diskusi tentang apa yang dilakukan kemarin dibatasi pada tugas-tugas di papan tulis atau semua pekerjaan yang dilakukan?

Saya tahu bahwa aturan Scrum dalam standup harian mengatakan bahwa tim hanya boleh berbicara tentang apa yang mereka lakukan kemarin, apa yang mereka lakukan hari ini, dan apa pun yang menghalangi mereka. Tidak ada lagi. Tetapi masalahnya adalah, kadang-kadang pengembang menghabiskan hari mereka melakukan pekerjaan yang tidak relevan dengan tugas mereka, dan kemudian membicarakannya di standup. Itu yang mereka lakukan kemarin!

Dalam pengalaman saya, saya menemukan bahwa lebih efektif untuk berbicara tentang tugas-tugas di papan tulis, untuk menjaga fokus tetap, dan untuk menjaga fokus semua orang pada tugas mereka, untuk meninjau estimasi mereka & melacak catatan mereka setiap hari.

Apakah valid untuk membatasi diskusi dengan tugas-tugas di papan tulis?

Sesuai konten Panduan Scrum pada standup harian, tiga pertanyaan untuk diskusi adalah:

• Apa yang saya lakukan kemarin yang membantu Tim Pengembangan memenuhi Sasaran Sprint?
• Apa yang akan saya lakukan hari ini untuk membantu Tim Pengembangan memenuhi Sasaran Sprint?
• Apakah saya melihat ada halangan yang menghalangi saya atau Tim Pengembangan untuk memenuhi Sasaran Sprint?

Semua pertanyaan fokus pada Tujuan Sprint, bukan tugas yang ada di papan tulis. Sekali lagi, sesuai Panduan Scrum, Tujuan Sprint dibuat dalam Perencanaan Sprint dan mendefinisikan "sebuah tujuan yang akan dipenuhi dalam Sprint melalui implementasi Product Backlog, dan memberikan panduan kepada Tim Pengembangan tentang mengapa ia membangun Kenaikan".

Segala sesuatu yang dilakukan oleh tim pengembangan Anda harus, secara ideal, membantu tim berkembang menuju Tujuan Sprint. Ini mungkin kegiatan yang tidak direncanakan yang tidak ada di papan tulis yang harus dilakukan, atau bisa saja hal-hal di tingkat yang lebih rendah yang mungkin telah dipertimbangkan dan diperkirakan, tetapi pada tingkat yang lebih rendah daripada item di papan tulis.

Saya akan mengatakan biarkan tim Anda berbicara tentang semua yang mereka lakukan kemarin. Jika mereka berbicara tentang hal-hal yang tidak membantu tim mencapai Tujuan Sprint, maka seseorang harus mengemukakan hal ini, terutama jika ada hal-hal lain yang bisa mereka lakukan yang memindahkan tim lebih dekat untuk menyelesaikan Tujuan Sprint.

Satu pengecualian mungkin jika seseorang mendukung beberapa tim Scrum. Dalam pertemuan itu, mereka mungkin tidak boleh berbicara tentang semua yang mereka lakukan kemarin, tetapi apa yang mereka lakukan untuk mendukung tim yang saat ini memiliki standup.

The Sprint Retrospective adalah waktu yang tepat untuk berbicara tentang masalah ini dengan tim. Ada banyak pertanyaan untuk dipertimbangkan:

• Apakah tim sedang mengerjakan item yang terkait dengan Sprint Goal?
• Apakah ada terlalu banyak pekerjaan yang tidak direncanakan?
• Dari mana karya yang tidak direncanakan berasal dan siapa yang mengotorisasi itu?
• Mengapa orang mengerjakan sesuatu yang tidak ada di papan tulis?
• Haruskah kita menunjukkan lebih banyak detail di papan tulis untuk mengikat hal-hal yang Anda lakukan dengan barang-barang di papan tulis dengan lebih mudah?

Tidak, Anda harus membicarakan apa yang Anda lakukan kemarin.

Jika tidak ada di papan tulis, Anda perlu melakukan salah satu dari yang berikut:

• letakkan di papan,
• berhenti melakukannya
• atau ganti tim.

Yang paling umum, katakanlah untuk pekerjaan darurat yang tidak direncanakan, adalah menulis kartu dan menempelkannya di papan tulis. Ini memastikan bahwa pada akhir sprint Anda dapat mengukur kecepatan dan menjelaskan mengapa tujuan sprint tidak tercapai.

Seorang anggota tim yang mengerjakan hal-hal yang tidak ada dalam sprint menurut saya salah satu alasan utama kegagalan adopsi tangkas. Paling umum ini adalah pengembang dialihkan untuk memperbaiki masalah langsung di proyek lain.

Hal menjengkelkan lain dalam sprint adalah "PM berbicara tentang pertemuan untuk proyek lain". Dalam pandangan saya PM bukan bagian dari tim scrum, mereka mengisi peran Scrum 'Pemilik Produk' dan dengan demikian ada untuk menjawab pertanyaan, bukan melaporkan kemajuan.