Apakah ukuran Story Point untuk tugas yang berulang berubah setelah Anda mengotomatiskan tugas?

8

Inilah situasi Scrum:

Tugas tertentu (menerapkan tabel data populasi akhir) adalah cerita yang sering
Tabel sering memiliki fungsi yang mirip tetapi kustom
Setiap tabel membutuhkan waktu sekitar satu minggu untuk diterapkan (8 poin cerita)
Akhirnya tim berinvestasi 4 minggu untuk membuat komponen yang dapat digunakan kembali
Sekarang membuat tabel baru hampir instan

Pertanyaan saya: Apakah tabel cerita baru masih 8 karena output / kompleksitas belum berubah? Atau 1 karena usaha minimal?

Penelitian Saya: Ketika saya mengambil pelatihan scrum dengan Jeff Sutherland, saya pergi dengan pemahaman bahwa cerita masih 8 karena poin cerita mengukur output. PM masih mendapatkan tabel yang sama, mereka hanya dikirim 5x lebih cepat. Ini peningkatan kecepatan asli (melakukan pekerjaan yang sama tetapi lebih cepat)

Tetapi saya ingin memverifikasi bahwa pemahaman saya benar. Ada bantuan di luar sana? Kami mencari definisi scrum formal, btw. Saya telah meneliti situs scrum inc dan membaca "Seni Melakukan Pekerjaan Dua Kali di Setengah Waktu" dan tidak dapat menemukan dokumentasi bahwa pemahaman saya benar atau salah.

Terima kasih!

Pembaruan Saya benar-benar mencari tautan ke dokumentasi oleh otoritas scrum resmi. Saya pikir pertanyaan ini menyesatkan sekarang karena banyak jawaban di bawah ini hanya pendapat orang.

agile scrum estimation

Saya pikir orang-orang memilih interpretasi scrum yang populer, bukan definisi formal yang diminta, itulah sebabnya jawaban teratas di sini tidak diterima

-2

PEMBARUAN 1/22: RESPONS SCRUM INC

"Itu tetap sama untuk mewakili pengiriman nilai yang sama. Kecepatan tim adalah ukuran utama. Peningkatan proses Anda harus menghasilkan peningkatan Kecepatan: https://www.scruminc.com/velocity/ " --- Scrum Inc. melalui Twitter

JAWABAN SINGKAT SAYA:

Jeff Sutherland, pencipta Scrum menjawab pertanyaan ini secara langsung dalam Poinnya vs. Jam Webinar pada slide 6

Apa itu Poin? Poin adalah ukuran OUTPUT tim. Berkorelasi dengan tetapi tidak harus sama dengan usaha.

JJ Sutherland, CEO Scrum Inc. menjawabnya lebih langsung dalam pelajarannya tentang Getting Velocity Right

Hanya karena tim telah menjadi lebih baik dalam mengimplementasikan cerita yang diberikan, nilai poin Anda harus tetap sama.

JAWABAN LAMA SAYA:

Sumber tambahan. Karena pertanyaan ini kontroversial, berikut adalah penelitian yang menjawab beberapa masalah yang disuarakan dalam jawaban lain:

Iya. Tujuan Scrum adalah untuk meningkatkan kecepatan

Sumber 1

Meskipun kecepatan cenderung berosilasi dari waktu ke waktu, sebagai aturan itu harus cenderung naik sekitar 10% per Sprint. - JJ Sutherland

Sumber 2

Slide 5 dari Lesson on Velocity dari Scrum Inc menunjukkan grafik kecepatan dengan peningkatan 12x dari waktu ke waktu DAN judul grafik "Peningkatan Output" dengan "Poin" sebagai sumbu y:

Sumber 3

Buka ScrumLab.scruminc.com dan lihat webinar Metrik. Ini menunjukkan bagaimana kami mengukur kinerja perusahaan menggunakan peningkatan kecepatan, metrik kebahagiaan, dan pendapatan per poin. Saya mendengar begitu banyak tim lambat mengeluh bahwa berjalan lebih cepat hanya akan menghasilkan lebih banyak omong kosong. Ini karena Pemilik Produk tidak bertanggung jawab atas penggandaan pendapatan per poin. Jika Anda menggandakan kecepatan dan menggandakan pendapatan per poin, perusahaan akan menghasilkan uang empat kali lebih banyak. Ini akan membuat semua orang senang. Itu sebabnya Anda membutuhkan tiga metrik. - Jeff Sutherland

Iya. Poin Cerita Mengukur Output / Produksi

Sumber 1

Metrik manajemen untuk pengiriman proyek perlu menjadi unit produksi Jeff Sutherland dalam artikel definitifnya Mengapa Story Points Lebih Baik Dari Jam

Sumber 2

Jika Tim mulai memperkirakan cerita dengan nilai yang lebih rendah karena mereka mengeluarkan lebih banyak pengalaman dan cerita itu tampak lebih mudah, Velocity sepertinya tidak akan pernah membaik. Ini adalah salah satu alasan utama mengapa memperkirakan dalam jam tidak bekerja. - CEO Scrum Inc, JJ Sutherland

TIDAK. Meningkatkan Kecepatan Tidak Menghancurkan Prediktabilitas

Pertama-tama, sebagai PO atau prediktabilitas eksekutif sangat penting, tetapi produktivitas bahkan lebih penting. Sebagian besar PO jika diberi pilihan antara mempertahankan tingkat produksi atau secara signifikan meningkatkan produktivitas dengan mengorbankan beberapa kemungkinan kecil akan memilih peningkatan produktivitas. Yang sedang berkata, tradeoff adalah pilihan yang salah jika tim menggunakan pola scrum Cuaca Yesterday yang direkomendasikan untuk perencanaan sprint.

Menggunakan akal sehat ... jika sebuah tim menghasilkan 10 widget per minggu, maka temukan cara untuk menghasilkan 40 widget dalam seminggu; kecepatan mereka telah meningkat 4x. PO mendapatkan 4 kali lebih banyak widget dalam jumlah waktu yang sama. Menyebut bahwa kecepatan rata bertentangan dengan definisi kata.

IYA. Permainan Sistem Mungkin Jika Seluruh Tim Curang

Akhirnya - dimungkinkan untuk membuat game sistem, tetapi dimungkinkan untuk membuat game sistem apa pun. Scrum meminimalkan cerita pemetik buah ceri individu dengan menarik dari tumpukan yang dipesan dan dengan mengukur kecepatan berdasarkan tim, bukan pada basis individu. Jika Anda mengukur dev dengan kecepatan dev, Anda tidak melakukan scrum. Dan itu memitigasi game sistem melalui perkiraan dengan mendandani cerita sebagai sebuah kelompok. Untuk menambah perkiraan Anda, Anda harus melakukannya di depan grup dan grup harus berkolusi dengan Anda. Tetapi jika Anda ingin memainkan sistemnya, tidak masalah proses apa yang Anda gunakan. Scrum tergantung pada tim yang terdiri dari 4-6 karyawan yang termotivasi dan mampu yang tertarik untuk mencapai tujuan bersama; tetapi jika Anda memiliki karyawan yang selingkuh bekerja untuk game sistem maka proses Anda bukan masalah.

— Nathaniel Rink
sumber

Saya menghargai semua diskusi di sini, tetapi pertanyaannya adalah untuk mendokumentasikan jawaban resmi / resmi; tidak membahas opini subjektif. Saya pikir jawaban yang diberikan oleh Co-Creator Scrum dan putranya / CEO Scrum Inc. adalah jawaban yang menjawab pertanyaan ini dengan jawaban resmi yang pasti.

Satu-satunya masalah yang saya tidak bisa rujuk dengan jawaban ini adalah membandingkan cerita dengan ukuran yang sama. Jika Anda menemukan cara untuk menghasilkan 4x lebih banyak dari Widget A, tetapi bukan Widget B, dan Anda awalnya memperkirakan kedua widget masing-masing 5 poin, apakah itu berarti Widget B sekarang 20 poin?

— Greg Burghardt

3

Hm Saya mengerti analogi jalan Anda. Saya tidak berpikir jawaban ini pantas untuk suara turun, tapi saya pikir masalah mendasar di sini adalah bahwa orang akan menganggap bahwa jalan bebas hambatan 60 mil adalah jumlah titik cerita yang sama dengan jalan kerikil sepanjang 60 mil (kesulitan yang lebih besar ). Ini mengisyaratkan akar dari pertanyaan ini. Bagaimana Anda bisa berkomitmen pada empat tabel data poin 8-poin dan kemudian juga membenarkan mengapa Anda hanya bisa berkomitmen pada cerita Widget X 8-poin tunggal. Jika jawaban ini benar, maka poin cerita tampaknya rusak secara mendasar.

— Greg Burghardt

2

Pembenaran Anda tentang prediktabilitas tampaknya salah. Misalnya, jika selama sprint Anda mengambil 8 poin untuk melakukan tugas tetapi melakukan itu menghasilkan otomatisasi yang mengurangi waktu menjadi 1, ketika merencanakan sprint berikutnya Anda mungkin melihat bahwa sprint sebelumnya membawa Anda 8 poin untuk melakukan tugas yang sekarang membutuhkan 1. Anda akan salah merencanakan berdasarkan kebutuhan 8 poin, meskipun waktu yang sebenarnya adalah 1.

— Bryan Oakley

2

Jujur, saya pikir jawaban itu omong kosong, dan saya tidak peduli siapa yang menulis omong kosong itu. Jika presiden AS menulisnya, itu masih omong kosong. Poin cerita adalah alat, dan jawaban ini membuatnya tidak dapat digunakan sebagai alat.

— gnasher729

15

Kisah tabel back-end Anda tidak lagi membutuhkan delapan poin usaha.

“Story Point adalah unit ukuran relatif, diputuskan dan digunakan oleh masing-masing tim Scrum, untuk memberikan perkiraan relatif upaya untuk menyelesaikan persyaratan“

scrum.org

Jika Anda terus memperkirakan cerita tabel back-end di delapan poin maka Anda akan condong kecepatan Anda sebagai ukuran usaha per sprint.

Juga tidak jujur untuk terus menetapkan delapan poin untuk pekerjaan yang Anda tahu hanya membutuhkan satu titik usaha.

— Dan Wilson
sumber

Saya tidak berpikir itu bisa disebut tidak jujur. PO mendapatkan 5x lebih banyak tabel dalam jumlah waktu yang sama. Itu peningkatan kecepatan yang sah ... Tapi terima kasih atas tautannya. Saya akan membacanya sekarang. Masalah dengan usaha adalah bahwa saya tidak melihat bagaimana kecepatan tim dapat meningkat secara eksponensial dari waktu ke waktu jika setiap kali mereka mencari cara untuk melakukan sesuatu lebih cepat Anda mendefinisikan kembali ukuran cerita yang sama. Sepertinya itu akan melemahkan inovasi.

5

Ini hanya peningkatan kecepatan jika poin cerita adalah ukuran output, dan saya selalu melihat poin cerita didefinisikan sebagai ukuran usaha. Dalam pengalaman saya, diasumsikan bahwa tim akan menjadi lebih mahir dari waktu ke waktu. Jika saya perlu satu titik untuk menambahkan catatan ke database, dan saya kemudian membuat skrip untuk menambahkan satu miliar catatan, apakah kecepatan saya meningkat satu miliar poin? Itu tidak masuk akal. Kecepatan dapat meningkat seiring waktu, hanya saja tidak secara eksponensial.

— Dan Wilson

3

@NathanielRink. Poin cerita bukan ukuran produksi. Mereka adalah perkiraan upaya. Seperti dalam kutipan dans.

— Ewan

8

@NathanielRink, Masalahnya dimulai ketika Anda memiliki beberapa cerita berbeda dengan 8 poin, di mana beberapa di antaranya membutuhkan waktu 1 hari untuk menyelesaikan dan yang lain membutuhkan waktu 1 minggu. Kemudian poin cerita Anda menjadi tidak berguna untuk memperkirakan berapa banyak pekerjaan yang tim dapat ambil dalam sprint dan Anda perlu membuat estimasi kedua untuk mengetahui apa yang dapat Anda rencanakan untuk sprint berikutnya.

— Bart van Ingen Schenau

1

Mengenai komentar pertama Anda, jika pengembang benar-benar tidak mendapat insentif untuk berinovasi dengan mengurangi poin cerita ... mereka tidak terdengar seperti pengembang yang sangat baik bagi saya. Semua pengembang baik yang saya tahu ingin berinovasi dan ingin membuat program dan proses lebih efisien, terlepas dari poin cerita

— matt freake

10

Meningkatkan kecepatan bukanlah tujuan. Tujuannya adalah perencanaan yang andal.

Poin cerita adalah alat dalam loop umpan balik yang akan memberi tahu Anda, dari waktu ke waktu, apa kecepatan khas Anda. Ini kemudian akan memberi tahu Anda berapa banyak poin yang dapat Anda adopsi secara realistis dalam sprint. Kecepatan mungkin melayang sedikit dari waktu ke waktu tetapi jika berubah terlalu cepat itu tidak berguna. Peningkatan kecepatan yang tiba-tiba hanya akan memberi tahu Anda bahwa Anda masih tidak tahu apa yang Anda lakukan. Jadi, Anda ingin menjaga kecepatan Anda konstan, yang memberi tahu Anda perkiraan Anda baik dan kemungkinan akan bagus untuk sprint berikutnya.

Anda tahu output Anda tidak konstan, Anda menyadari fakta bahwa Anda dapat membuat tabel lebih cepat sekarang. Jadi itu akan benar-benar mengalahkan tujuan siklus perencanaan Anda jika Anda bersikeras menghubungkan poin cerita dengan hasil.

Sekali lagi, kecepatan tidak terkait dengan produktivitas dan kecepatan yang meningkat bukan alasan untuk merayakannya. Poin cerita pada akhirnya adalah sebagian dari sprint Anda. Untuk membuatnya lebih nyata, beberapa tim mendefinisikan tugas yang sudah diketahui oleh semua orang dan menyebutnya tugas poin cerita standar sehingga setiap pekerjaan dapat dikaitkan dengan tugas standar dalam hal kompleksitas dan konsumsi waktu. Tak perlu dikatakan jika tugas standar menjadi lebih mudah, semuanya akan berubah dan semua orang harus beradaptasi dengan makna baru dari satu titik cerita, yang menyebalkan. Cara yang tepat dan nyaman untuk pergi adalah mendefinisikan tugas standar baru yang sama-sama menantang bagi tim.

— Martin Maat
sumber

6

Poin cerita mencerminkan berapa banyak upaya yang diperlukan untuk mengimplementasikan cerita. Mereka adalah prediksi upaya. Jika jumlah usaha turun, demikian juga jumlah poin.

Ingat, poin adalah alat untuk membantu Anda memperkirakan. Tidak lebih, tidak kurang. Mereka bukan hadiah atau metrik yang mengukur output. Mereka hanyalah cara untuk memperkirakan berapa banyak pekerjaan yang akan terlibat dalam mencapai tujuan cerita.

Anda mengatakan tugas ini awalnya mengambil 8 poin, yang setara dengan sekitar satu minggu. Sekarang anggap saja sprint Anda berlangsung selama satu minggu, jadi dalam perencanaan Anda akan menurunkan 8 poin cerita. Jika Anda menyimpan cerita ini pada 8 poin maka Anda hanya dapat merencanakan untuk menyelesaikan cerita yang satu ini di sprint. Jika waktu sebenarnya hanya satu jam daripada 40 jam, apa yang akan Anda lakukan dengan 39 jam lainnya? Anda baru saja membuat rencana yang sangat buruk untuk sprint Anda karena poin cerita yang tidak akurat.

jika cerita lebih akurat direpresentasikan sebagai satu poin, itu berarti Anda masih bisa menarik 7 poin lagi dalam sprint satu minggu saat ini. Tampaknya itu mencerminkan realitas Anda lebih dekat, jadi mengubah ukuran cerita itu masuk akal karena membantu Anda merencanakan.

Anda menyebutkan dalam pertanyaan Anda keinginan untuk meningkatkan kecepatan, tetapi bukan itu yang seharusnya Anda lakukan. Setidaknya, tidak dalam arti harfiah. Produktivitas Anda secara alami akan meningkat, tetapi demi perencanaan nilai kecepatan Anda harus tetap cukup konstan.

— Bryan Oakley
sumber

4

Pikirkan efeknya. Katakanlah Anda memiliki tim yang terdiri dari lima orang, kecepatan 100 poin dalam sprint, dan Anda secara wajar mengharapkan semua orang menangani 20 poin. Sekarang Anda memiliki tugas ini yang telah menjadi sepele, tetapi masih mendapat delapan poin. Seorang anggota tim mengambil lima tugas ini, mengerjakannya dalam dua hari, meletakkan kakinya di atas meja selama delapan hari tersisa, mengalahkan semua orang dengan menangani tugas bernilai 40 poin, dan mendapat bonus. Semua orang diusir oleh bos.

Jika Anda senang dengan itu, maka jangan mengubah poin untuk tugas ini. Saya tidak akan menyukai situasi itu.

Setiap tugas dengan jumlah poin yang sama harus diharapkan untuk mengambil pengembang dalam jumlah waktu yang sama.

Dan saya benar-benar tidak setuju dengan jawaban Nathaniel di sini. Mempertahankan poin akan membuat kecepatan benar-benar tidak dapat diprediksi, karena beberapa tugas akan dilakukan lebih cepat, tetapi yang lain tidak, jadi lari cepat dengan tugas dipercepat akan memberi Anda kecepatan besar, dan selanjutnya berlari turun lagi.

Ini juga bukan perkiraan Anda. Jika saya tahu bahwa saya memiliki sepuluh tugas yang agak mirip, saya tidak memberi mereka poin yang sama sejak awal. Saya memberikan banyak poin untuk yang pertama, dimaksudkan untuk "melakukan tugas dan membangun alat untuk melakukan tugas serupa dengan sangat cepat", maka poin jauh lebih sedikit untuk tugas yang diulang.

Ini adalah situasi yang berbeda ketika pengembang junior memulai, atau pengembang bergabung dari tim yang berbeda, dan meningkatkan kecepatan mereka di lain waktu karena mereka belajar (bagaimana melakukan pekerjaan mereka di tempat pertama, atau semua bagian yang perlu mereka ketahui tentang yang khusus proyek).

— gnasher729
sumber