Saya perhatikan dalam rapat scrum, bahwa pengembang sering memberikan estimasi realistis tentang cerita. Namun, bahkan cerita yang agak sederhana memerlukan banyak upaya untuk konfigurasi, pengaturan komponen pihak ketiga, pengujian dan pembuatan akhir, dan sistem telah mengakumulasikan cukup banyak hutang teknis, sehingga perkiraan seringkali tampak terlalu tinggi untuk pemilik atau manajemen produk.
PO sering mencoba untuk mengalahkan perkiraan seperti itu, seperti: "Apa, Anda ingin 13 poin cerita [4 hari] untuk cerita ini, ini tidak mungkin! Saya tidak bisa menjelaskan ini kepada manajemen, seseorang harus dapat kode ini dengan 3 SP [dalam 4 jam]! " Akibatnya, para pengembang memutar tangan mereka untuk berkomitmen pada perkiraan 5 atau 8 poin poin [1,5 hingga 2 hari] (perkiraan Scrum masih dianggap sebagai komitmen, bukan hanya perkiraan).
Tentu saja, tanpa rencana untuk menurunkan harapan (terutama pada pengujian dan kualitas), sprint ini sering gagal. Perkiraan pengembang adalah jujur, realistis, dan mengalahkan perkiraan tidak mengalahkan pekerjaan yang sebenarnya harus dilakukan.
Seseorang dapat mengatakan: "Anda seharusnya tidak membuat komitmen yang mustahil, hanya karena seseorang mendorong Anda untuk melakukannya!" Tetapi menurut saya, pekerjaan pengembang adalah desain dan pengkodean perangkat lunak, bukan tawar-menawar atau menghadapi tekanan! Mungkin ada jacks dari semua perdagangan, biasanya yang berhubungan langsung dengan pelanggan eksternal, tetapi ini bukan mayoritas pengembang kantor!
Bagi saya, praktik ini hanya membuat pemrogram terlihat seperti tersentak, menyebabkan kegagalan sprint konstan dan mencegah estimasi realistis, serta mencari perbaikan yang sebenarnya.
Apa yang dikatakan pedoman Scrum tentang topik ini, atau apakah mereka mengatakan sesuatu tentangnya?
EDIT: diganti kali dengan poin cerita. Saya mengacu pada tahap estimasi awal dengan Perencanaan Poker dan poin cerita, bukan perencanaan detail tugas. Saya hanya menempatkan hari / jam di sana, karena itu adalah dialog khas seperti ini kadang-kadang, juga dengan waktu, bukan poin. Maaf atas kebingungan! Contoh-contoh titik cerita mewakili periode waktu yang lebih lama daripada contoh waktu.
EDIT 2 Saat ini tidak ada master scrum khusus, dan PO mengambil peran itu, ketika datang ke pertemuan estimasi. Jadi mungkin konflik peran membuat tawar-menawar yang tidak pantas ini menjadi lebih buruk, karena ia muncul sebagai otoritas, bukan master scrum netral atau pengembang. Mungkin, ini bisa diperbaiki dengan menganggapnya sebagai peserta yang bias alih-alih "master", selama tidak ada yang tersedia.