Timeboxing: Süreyi Sabitleyip Kapsamı Yönetmek

Timeboxing nedir, neyi değiştirir?

Klasik planlamada kapsam sabit tutulur, süre ve maliyet ise işin gerektirdiği kadar uzar. Timeboxing bunu tersine çevirir: süre sabittir, kapsam esner. Ekip, belirli bir dönem için anlaşır ve o dönemin içinde en değerli çıktıyı üretmeye çalışır. Yeni iş keşfedilirse zaman kutusu büyütülmez; ekip hangi işin içeride kalacağını, hangisinin sonraya ertelendiğini yeniden belirler.

Bu yaklaşımın gücü karar anının öne çekilmesindedir. Kapsam çok büyükse bu durum teslim tarihine yaklaşırken değil, kutunun planlandığı anda ortaya çıkar. Ekip baştan 'hepsi sığmayacak' der ve önceliği açıkça belirler. Böylece son güne bırakılan, yarım kalan ve test edilmemiş işler azalır.

Timeboxing, kişisel verimlilikteki zaman bloklamayla karıştırılmamalıdır. Zaman bloklama bir kişinin takvimini işlere paylaştırmasıdır. Proje bağlamındaki timeboxing ise bir ekibin teslimat taahhüdünü sabit bir süreye bağlar, kapsam üzerinde pazarlık yapar ve her dönemin sonunda bir çıktı gösterir.

Zaman kutusunun ölçekleri

Zaman kutuları tek bir uzunluğa bağlı değildir. AgilePM yaklaşımında dört ölçek ayırt edilir.

• Toplantı ya da atölye zaman kutusu: kısa bir süre; karar vermek, plan yapmak veya bir sorunu çözmek içindir.
• Teslimat zaman kutusu: birkaç haftalık dönem; seçilen iş kalemleri geliştirilir, test edilir ve gösterilir. Scrum'daki Sprint bu ölçeğin bir örneğidir ve bir ay ya da daha kısa sürer.
• Proje artışı zaman kutusu: birkaç teslimat kutusunu içeren daha geniş bir planlama ufku; bir sonraki artışa geçmeden önce gözden geçirilir.
• Proje zaman kutusu: projenin başından sonuna kadar olan tüm süre.

Bu ölçekler iç içe çalışır. Proje zaman kutusu içindeki artışlar teslimat kutularına, teslimat kutuları da günlük ve haftalık toplantılara bölünür. Süre kısa tutulduğunda geri bildirim hızlanır ama gösterilebilir çıktı küçülür; uzun tutulduğunda kapsam şişer ve sapma geç fark edilir. Uzunluğu ekibin geri bildirim ihtiyacı ve işin belirsizliği belirler.

MoSCoW ile kutunun içindeki işi seçmek

Süre sabitse hangi işin kutuya gireceği önem kazanır. MoSCoW dört kategori sunar.

• Must Have: kutunun başarılı sayılması için teslim edilmesi şart olan işler. Bu işler birlikte 'en küçük kullanılabilir küme'yi oluşturur.
• Should Have: önemli, ama olmasa da çıktı çalışır. Ertelenebilirler.
• Could Have: olsa iyi olan işler. Gerektiğinde ilk çıkarılan kalemler bunlardır; kutunun emniyet payı gibi davranırlar.
• Won't Have this time: bu kutuda kapsam dışı bırakılan işler. Kategori en az önemsenen gibi görünür ama en çok sorunu önleyen kategoridir, çünkü ekibin neyi yapmayacağını açıkça yazar.

Pratik kural şudur: yük planlanırken Must işleri kutunun tamamını doldurmamalıdır. Aksi halde esneklik kalmaz, ufak bir aksaklık bütün taahhüdü tehlikeye sokar. AgilePM kılavuzu Must işlerin kullanılabilir efor içindeki payını sınırlı tutmayı ve Could işlerine yer ayırmayı önerir; bunlar yönerge niteliğindedir, kesin kural değildir. Süre daralırsa önce Could, sonra gerekirse Should işleri çıkarılır.

Kurgusal bir örnek: müşteri portalı teslimatı

Bir ekip müşteri portalının ilk sürümünü sabit bir tarihte yayına almak zorunda olsun. Başlangıçta liste uzundur: giriş, fatura görüntüleme, ödeme, bildirim tercihleri, profil fotoğrafı, koyu tema, gelişmiş filtreler.

Ekip önceliği şöyle koyar. Giriş ve fatura görüntüleme Must'tır, çünkü bunlar olmadan portal anlamsızdır. Ödeme Should'dur: önemli ama ilk sürümde müşteri faturayı portaldan görüp başka kanaldan ödeyebilir. Bildirim tercihleri ve profil fotoğrafı Could'tır. Koyu tema ve gelişmiş filtreler bu kutu için Won't'tur ve bir sonraki kutunun adayıdır.

Kutu ortasında entegrasyon beklenenden uzun sürer. Süreyi uzatmak yerine Could işleri çıkarılır; Should işi ödeme küçültülür. Kutu sonunda giriş ve fatura çalışır ve gösterilir; ekip gösterimden gelen geri bildirimle bir sonraki kutunun listesini günceller. Teslim tarihi korunmuş, kapsam ise bilinçli biçimde daralmıştır.

Bir zaman kutusunu adım adım yürütmek

Kutu bir döngü olarak işler. Başlangıçta ekip işleri MoSCoW'a göre sıralar ve Must işleri belirler. Çalışma sırasında ilerleme görünür tutulur: kısa günlük toplantılarda kutunun hedefine göre durum kontrol edilir. İş beklenenden büyükse karar alınır: kapsam daraltılır, işin parçalarına ayrılması düşünülür ya da Could işler çıkarılır, ama süre uzatılmaz.

Kutu sonunda çıktı gösterilir. Bu gösterim hem paydaşlardan geri bildirim almayı hem de yapılan işin gerçekten kullanılabilir olup olmadığını görmeyi sağlar. Ardından ekip öğrendiklerini kaydeder: tahminler neden tutmadı, hangi işler beklenenden büyüktü, hangi öncelik yanlış çıktı? Bu öğrenme bir sonraki kutunun planına girer.

İş gerçekten tamamlanmadıysa kalan kısım otomatik olarak yeni kutuya devredilmez. Önce yeniden değerlendirilir; hâlâ en değerli iş mi, yoksa değeri değişti mi? Bu soru, bitmemiş işlerin sessizce birikmesini engeller.

Sık hatalar ve önlemler

Timeboxing'in en sık bozulduğu noktalar şunlardır.

• Süreyi 'bir kereye mahsus' uzatmak. Bir uzatma ikincisini getirir ve kutu anlamını yitirir. Kapsamı daraltmak her zaman bir seçenektir.
• Her şeyi Must işaretlemek. Öncelik ayrımı kalmazsa sıkışınca neyin çıkarılacağı belli olmaz.
• Won't kategorisini boş bırakmak. Neyin yapılmayacağı yazılmazsa istekler kutuya sızar.
• Gösterimi atlamak. Çıktı gösterilmezse ilerleme kanıtlanamaz ve geri bildirim kaybolur.
• Bitmemiş işi sessizce devretmek. Her devir yeniden önceliklendirmeden geçmelidir.
• Kutuyu yük taşıma aracı saymak. Amaç herkesi sürekli meşgul tutmak değil, değerli çıktıyı zamanında vermektir.

Süre baskısı altında çalışırken kaliteden ödün vermek de yaygın bir tuzaktır. Zaman kutusunda esneyen kapsamdır, kalite değil. Test edilmemiş bir iş kutuya sığmış sayılmaz; kapsamdan çıkarılıp sonraki kutuya bırakılır.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Agile Project Management Foundation eğitimi çevik proje yönetimi çerçevesini ele alır; zaman kutusu ve önceliklendirme bu çerçevenin temel mekanizmalarındandır. PRINCE2 Agile Foundation & Practitioner Hazırlık Eğitimi ise esnek planlama ve kontrol mekanizmalarını PRINCE2'nin yönetim yapısıyla birleştirir. Proje yöneticileri, ürün sahipleri ve takım liderleri için kapsamı pazarlık konusu yapmanın ölçülü bir yolunu öğretir.