Kullanıcı hikayelerini tahmin ederken neden insan günleri yerine hikaye puanları kullanıyoruz?

Çevik metodolojilerde (örneğin SCRUM), kullanıcı hikayeleri için gereken karmaşıklık / efor Hikaye noktalarında ölçülür. Öykü noktaları, bir ekibin bir yinelemede kaç kullanıcı öyküsü alabileceğini hesaplamak için kullanılır.

Tahmini adam günleri gibi somut bir ölçüm kullanabileceğimiz soyut bir kavram (hikaye noktaları) sunmanın avantajı nedir? Tahmini insan günlerini kullanarak hızı, bir yinelemenin kapsamını tahmin etmeyi de hesaplayabiliriz.

Aksine, hikaye noktalarının kullanımı daha zordur (çünkü kavram soyuttur) ve ayrıca paydaşlara açıklamak daha zordur. Hangi avantajı sağlıyor?

Bence asıl avantajlardan biri, insanların ve geliştiricilerin zaman tahmininde özellikle oldukça kötü oldukları düşüncesindeyim. Gelişimin doğasını da düşünün - başlangıçtan bitişe doğru doğrusal bir ilerleme değil. Genellikle "kodun% 90'ını 10 dakika içinde yazıp saçınızı 17 saat boyunca hata ayıklamadan ayırın". Saat zamanlama anlamında tahmin etmek oldukça zor.

Ancak bir soyutlamanın kullanılması, odağı gerçek zamanın saat veya gün olarak ortadan kaldırmasına neden olur ve bunun yerine görevin diğer görevlere kıyasla göreceli masrafını ve karmaşıklığını açıklamaya odaklanır. İnsanlar / geliştiriciler bu konuda daha iyidir. Ve sonra, bu nokta tahminleriyle ve bazı gerçek ilerlemelerle mırıldanmaya başladığınızda, zamana daha ampirik olarak bakmaya başlayabilirsiniz.

Ayrıca, nokta tahminleriyle gerçekleşmeyecek zaman tahminleriyle gerçekleşen bir gözlemci etkisinin de bulunduğundan şüpheleniyorum. Örneğin, bir tahminin kumlanmaya teşvik edilmesi ve “programın öncesinde” bir yol göstermesi, puan tabanlı bir sistemde dolaylı olarak susturulacaktır.

Fibonacci sayılarını (veya benzer bir şeyi) kullanıyorsanız, bir hikayeyi tahmin ederken seçenek sayısını sınırlar. Yalnızca düşük sayıları kullanan bir grupla çalıştım: 1, 2, 3, 5, 8 ve 13. 5 olan bir referans hikayemiz vardı. Bu, Planlama Poker'i yaparken bir hikayenin karmaşıklığı üzerine kolayca karar vermemizi sağladı. . Diğer yan etki, 13 puan alan herhangi bir şeyin muhtemelen yeterli bilgiye sahip olmadığı ve daha fazla parçalanması gerektiğidir. Ham saatler kullanıyor olmamızın bu kadar kolay ve kolay olacağını düşünmüştüm.

Ürün Sahibi, paydaşlarınızın dilini konuşur ve gerektiğinde hikaye noktaları ile çalışma saatleri (veya diğer birimler) arasında çeviri yapabilmelidir. Bir PO olarak geçirdiğim süre boyunca, 1 hikaye noktası = 4 adam-saat, ama belli ki her takımın farklı olduğu konusunda bazı zor verilerim vardı.

Düzenle:

1 puan = 4 saat olduğu bilgisiyle, Planlama Poker destenizi teorik olarak 4, 8, 12, 20, 32 ve 52 olarak değiştirebilirsiniz. Fakat bu sayılarla başa çıkmak daha zor. Değerleri zihinsel olarak basit bir şeye soyutlayacağımı düşünüyorum, örneğin, "bir günden az", "bir haftadan daha fazla", vb. -sız hikaye noktaları.

Tahmin edicilerin tahminlerini ayarlamaları gerekmeden tahminlerin zaman içinde iyileşmesini sağlamak.

Tahminde yer alan herkesin "Tamam .. 2 adam gününe benziyor ... ama son sprint gibi her şeyi hafife aldıklarını düşünmek yerine, her zaman olduğu gibi devam ediyorlar, yani belki de 2.5 adam günü. İnternethaber.com "5 hikaye puanı!"

Ardından, takımın bir sprintte kaç hikaye puanı elde edebileceği konusundaki tahminlerinizi önceki sprintlerdeki gerçek ölçülen başarıya dayanarak ayarlarsınız. “Daha önce sprint başına 90-110 hikaye puanı yapıyoruz!”

Bunun arkasındaki teori, geliştiricilerin farklı dev görevlerin göreceli karmaşıklıklarını tahmin etmede mutlakları tahmin etmekten daha iyi olduğunu söyleyebilirim . Özellikle birden fazla kişi, herhangi birinin yapabileceği bir işi tahmin ediyorsa (ve herkes herkesle aynı hızda çalışmaz).

Sinik alternatif: Geliştiricilerin asla zaman tahminleri altında gelmediklerini söylediğini gördüm. Bir şey tahmin edilenden daha uzun sürerse, siz geçtiniz. Fakat eğer bir şey tahmin edilenden daha az zaman alırsa , geliştiriciler onunla alt üst olabilir, altın plaka yapabilir veya sadece yavaşlatıp rahat bir görev verildiği için rahatlatabilir. Gerçek zaman birimlerinin bir tahmin dışı bırakılması bu eğilimleri engelleyebilir. Sinik alternatifini sonlandır.

Erkek günleri veya erkek saatleri sizin dediğiniz gibi. Yani bir görev 5 saat olarak tahmin edildiğinde ve 6'yı aldığında artık geç bir görevdir.

3 puanlık bir hikayeniz olduğunda ve 6 saat sürdüğünde, 6 saat sürdü, geç değildi, sadece altı saat sürdü. Hız ölçümü, bir sprintte bu noktaların kaç tanesinde bulunduğunuzu ve bu sayının dalgalanabileceğinin bir faktörüdür, çünkü somut değildir. Ayrıca her bir görevi değil, tüm görevlerin toplamını ölçüyorsunuz. Her görevde saatiniz olduğunda, her görevi ölçmek için ayartma vardır. Bu gerçekleştiğinde, zaman içinde bitirmek için sprint için hiçbir fayda elde edemezsiniz ve verilen herhangi bir işin süresi içinde bitirmenin bir sonucudur.

Düşünceye puan açısından bir geçiş olabilir. Daha önce çalıştığım bir yer, eforla ilgili fikir edinmek için çevik tişört bedenlerini bile tanıttık. Puanlar bunun sadece bir uzantısıdır.

Bu, tartışmanın olmadığı veya noktalara keyfi bir şekilde verilmediği anlamına gelmez. Neredeyse her zaman en düşük sayıya oy veren ekibimizin üyeleri var ve bir görevin 1 olduğunu düşündüklerinde şikayet ediyorlar ve puan enflasyonundan dolayı acı çektiğimizi düşünüyoruz.

Soyutlama bir tür meseledir. 'İnsan gününü' bir ölçüm olarak kullanmak, aşağıdakileri içeren bir takım tuzaklara sahiptir:

1. Ekip kullanacakları teknolojiye aşina değilse, bir görevin ne kadar süreceği konusunda gerçek zamanlı tahminler vermek gerçekten zor olabilir. İyi göreceli tahminlerde bulunma olasılıkları çok daha yüksektir - örneğin, "A görevi muhtemelen B görevinin iki katı kadar sürecektir".
2. Farklı insanlar farklı oranlarda çalışıyor! Eğer 'adam günleri' kullanıyorsanız, bir görev bir geliştiriciden diğerine geçtiğinde tahmin zamanını değiştirmeniz gerekir. Zaten ne kadar çalışmanın bir “erkek günü” oluşturduğunu kim tanımlar?

Erkek günlerini tahmin etmek istiyorsanız, basit bir hesaplama:

user points in story / average user points per developer per day = estimated man days

Daha önce de belirtildiği gibi, hikaye noktaları göreceli bir karmaşıklık ölçütüdür. Tahmin için 2 serinin (1,2,4,8,16 ...) veya Fibonacci ölçeğinin (1,2,3,5,8,13,20 ...) gücünü kullanabilirsiniz. Tecrübeli geliştiriciler, böyle bir şey söylemekte oldukça beceriklidir:

A Özelliği, B Özelliğinin neredeyse iki katı kadar zor

Ancak bu özelliğin uygulama için ne kadar süreceğini 'söylemek gerçekten zor. Bunun hız ile dengelenmesine izin verdin. Eğer bir şey 5 olarak tahmin edilmiş ancak 13 olduğu ortaya çıktıysa, daha yavaş bir hız yineleme için (ya da yeniden tahmin edebileceğiniz) normalize olur.

Şimdi, başka bir alternatif var, buna 'ideal günler' denir (bazıları erkek günlerine benzeyen ancak bunun ne anlama geldiğinden emin değilim) ve bunu tercih eden birkaç ekip biliyorum. İdeal günler şöyle yorumlanır:

Göreve geldikten ve sadece gerekli araları verdikten sonra yaptığım şey buysa, kesinti olmaz ve 'hikayeyi uygulamak için' ihtiyacım olan her şeye sahip olursunuz;

Çok iyi bilinen çevik misyonerlerden biri olan Mike Cohn, hikaye noktaları ve ideal günler arasında aşağıdaki karşılaştırmayı sağlar:

Öykü Noktaları

• İşlevler arası davranışı yönlendirmeye yardımcı olur, yani ekipler, toplam uygulama karmaşıklığıyla ilgili hikayeleri kullanıcı arabiriminden DB'ye kadar geri tahmin eder.
• SP tahminleri bozulmaz, yani bundan birkaç ay sonra 5 puanlık bir hikaye hala 5 puan olabilir, ancak ideal bir gün tahmini bu programcının kazanılmış geliştirme becerisine / hızına bağlı olarak değişebilir.
• SP, saf boyut ölçüsüdür, yani bunlar sadece ve sadece boyut karmaşıklığını yansıtır. Dönemi. Süre yok, attı. Bu hızın işi. Ama ideal günlerde öyle değil. Aslında ideal günlerde takvim günleriyle karıştırılma eğilimi vardır. Onu SP olarak soyut tutmak, gerçeklikle karşılaştırmak için caziptir. Sadece bir ölçü ölçüsü. Saçmalama.
• Genellikle ideal günlerden daha hızlıdır. İlk birkaç hikaye için biraz zor olabilir, ama bir kere anladığınızda, daha hızlı.
• Farklı geliştiriciler, bir hikayeyi tamamlamak için ideal gün tahminlerini farklı bir şekilde değerlendirebilirler. Ben aynı şeyi 3'te yapabilirim, sen de 5'de yapabilirsin. Konuşmak için oyun alanını düzleştirirler.

İdeal Günler

• Takımın dışında açıklamak daha kolay; bariz sebeplerden dolayı :)
• Yukarıda belirtildiği gibi ilk bakışta tahmin etmek daha kolaydır. Ama bir kez SP'lerin ertelenmesiyle doğal olarak gelir.

Şimdi, hangisini seçmelisiniz takıma bağlı. Ancak, buradaki çoğu cevap ve kişisel deneyimim olarak hikaye noktalarını tercih ederim. İdeal günler gerçekten de SP'ler üzerinde bu kadar fazla kazanca sahip değiller (ve Mike Cohn, SP'yi diğer çevik saldırganlar ile birlikte savunuyor).

Öykü noktaları ayrıca ekibin zaman içindeki performansını iyileştirmeyi ölçmenize yardımcı olur. Ek olarak, performans arttıkça her şeyi yeniden tahmin etmeniz gerekmez.

İnsan günlerini kullanan bu örneği ele alalım:

Ekip, insan günleriyle farklı görevleri tahmin ediyor. Bir süre çalışır, ancak bir süre sonra ekibin ilk başta sanıldığından çok daha hızlı bir şekilde yapıldığını görürsünüz. Bu yüzden takım görevleri yeniden tahmin ediyor. Bir süre çalışır ve bir süre sonra tekrar aynı şeyi görürsünüz: Takım daha hızlı bir şekilde birçok görevle daha hızlı bir şekilde yapılır. Yani tekrar tahmin ediyorsun ve bu hikaye tekrar ediyor, tekrar tekrar ...

Neden? Çünkü ekibinizin performansı arttı. Ama sen bunu bilmiyorsun.

Hikaye puanlarıyla aynı örnek:

Ekip , kullanıcı hikayelerinin boyutunu tahmin eder . Bazı sprintlerden sonra takımın sprint başına yaklaşık 60 hikaye puanı kazanabileceğini görüyorsunuz. Daha sonra, takımın 60'tan fazla hikaye puanı, belki 70'in üzerinde olduğunu görüyorsunuz. Ve takım böyle devam ediyor ve sonraki sprintler için daha fazla kullanıcı hikayesi çekiyor ve yayınlıyor.

Neden? Çünkü performans arttı. Ve bunu ölçebilirsin. Ve ekibinizin performansı yükseldikten sonra her şeyi yeniden tahmin etmeniz gerekmez.

İlk olarak, insanlar göreceli tahminlerde mutlak tahminden daha iyidir. Babylonluların yıldızları göreceli parlaklığını haritalamak ve derecelendirmek buna güzel bir örnektir. Mutlak rakamları doğru anlayamadılar, ancak sipariş çoğu zaman benzer yoğunluklarda bile belirlendi.

İkinci avantaj, bu alıştırmayı yapmak için en önemli nedenlerden biri de sohbeti başlatmaktır.

Napolyon'un dediği gibi: plan değersizdir, planlama paha biçilmezdir.

Üçüncüsü, proje yöneticisi tüm tahminleri düzenlemek zorunda değildir, çünkü tahminlerin% 130 gibi bir faktöre bağlı olmadığı ortaya çıkmıştır.

Öykü Noktaları, sorunun karmaşıklığını yansıtır ve bu nedenle tahminin ne kadar doğru olduğuna dair güven (veya riski) yansıtır.

Öykü noktası yüksek olan bir hikaye, kullanıcı hikayesinde somut olmayan bir sürü şey olduğunu söylüyor.

Fikir, değişen hikaye noktalarının neyin iyi bir dengede olduğunu görmek. Tüm yüksek öykü noktalarına sahip hikayelere sahip bir yineleme planı gösteriliyorsa, bu yinelemenin beklendiği gibi yürütüleceğine ve yineleme için diğer hikayelere bakmamız gerektiğine veya hikayeleri parçalamaya başlamamıza çok az güven veriyor.

Bir yönetici veya Ürün Sahibiyle iletişim kurarken, yüksek hikaye puanları, belirli bir özelliğin ne zaman olacağı konusunda son derece tehlikeli olacağı anlamına gelir. Bunun çözümlerinden biri, hikayeyi yıkmak ve umarım Ürün Sahibine ilerlemeyi gösterebilmeniz için birlikte çalışacak düşük ve yüksek hikaye noktalarının bir kombinasyonuna sahip olursunuz.

İnsan günleri bir şeyin yapılacağı zamanı tahmin eder. En iyi tahmin ettiğiniz öğeler çok kesin ve ölçülebilir olduğunda kullanılırlar. Belirli, iyi bilinen, tekrarlanabilir görevler insan günlerinde tahmin edilebilir.

Örneğin, bir satış elemanı günde 20 müşteri araması yapabilirse, ortalama olarak, her bir aramanın ne kadar zaman alacağını hesaplayabiliriz ve bundan 1000 kişi için kaç adam günü süreceğini tahmin edebiliriz.

Bu örnekte, bir çağrının ortanca uzunluğu ile ilgili istatistiksel terimler somut olarak düşünülebilir, çünkü tüm çağrıların aynı şey olduğu kabul edilebilir.

Öykü noktaları , bir yinelemede hangi öykü kombinasyonunun yapılabileceğini belirler. Heterojen hedefleri bulanık sınırlarla birleştirmek ve sabit bir zaman diliminde kaç kişinin yapılabileceğini ölçmek için kullanılırlar. İş topaklarının karmaşıklığını, birbirlerine ekleyebilmeleri için birbirlerine göre tahmin ediyorlar .

Örneğin, ekibiniz yineleme 1'de toplam 23 puan için 5 hikaye ve yineleme 2'de 20 puan için 8 hikaye geliştirdi. Bundan, yineleme 2'de ekibinizin toplamı yaklaşık 20 puan olan birkaç hikaye yapacağını tahmin edebilirsiniz. yinelemede 3.

Bir noktanın boyutunu belirlememiz gerekmediğine ve özellikle aynı boyuttaki her hikayenin geliştirilmesinin aynı zaman alacağına dair hiçbir varsayımın olmadığını unutmayın! Yalnızca yineleme başına toplamlar ve puanlar üzerinde çalışırız. Yinelemenin ne kadar sürdüğünü bile söylemedim.

Eğer sokakta bir insana doğru yürür ve "Bir T-rex ne kadar büyüktü?" Diye sorarsanız. İnsanların çoğunluğu bir T-rex'in ne olduğunu, ne kadar büyük olduğunu bilseler de, ancak kesin olarak kimse bilmiyorsa, çünkü cevaplar dalgalanacaktır.

Yani tahmini ile anlamaya çalışıyoruz bilişsel davranış ve birçok metodolojileri ile döngüleri dönmeye " Buldum! .. ı doğru tahmin sırrı var! " Yılan yağı kitlelere. Aslında tahminlerde bulunduğunuzda, " Bunun tamamlanması için x gün / saat / puan İZİN VERECEĞİM" diyorsunuz.

Benim için Puan, sınırları değiştiriyor, günün sonunda, "söylemekten mutlu bir takım olmadıysanız" * Eh, sprint başına 3 haftanız var ve başparmak emmek ... ateş etmemiz gerektiğini düşündüm Bu döngünün tamamlanması için 30 puan! Kim benimle! * "Ve tahmin modeline girdiğin kadar derin - tamam! .. gerçekçi olarak, yalnızca bir bütçe bütçesi belirliyorsunuz ve hepsi bu. Aynı zamanda geriye dönük olarak “kutsal bir saçmalık duygusu ile tamamlanan işlere baktığımda, 33pts yaptık, çok güzeldi” ve bu konuda çok fazla şey yapamadık. Bütçenin karşılığını aldığın orta süratli tahtayı belirlemek için hızı kullanıp, "Henüz 15 puan aldın mı?"ama buradaki tehlike şu an ürettiğim kapasiteyi değil ölçmek için Velocity'i kullanıyorsunuz ki bu benim anladığım kadarıyla Reaktif Yayın Yönetimini (hikaye noktaları) başa vuruyor.

Puan sistemi hala denkleme göreli zaman takmak olduğunu fark etmek neredeyse çok zeki, hesabınızla ilgili her şeyi süresi + karmaşıklığı = etrafında bazı gizli kuralı yürürlüğe ettiği günlük Stand Figürler için "sürat döngülerini" kabul etti " Maksimum uzun sürüyor Bu görevde "doğuştan gelen içgüdü bir takım kodu kırmızı an mı hissediyorsunuz?"

İnsan beyni, uzun / kısa süreli hatırlama ile karıştırılan çok sayıda çalışma hafızası içerdiği için tahmin edemez, bu yüzden acemi bir matematik öğrencisinin kâğıt üzerinde değil kafasında kesirler yapmalarını istemek gibi bir şeydir. Göreceli bir zamanda öngörüleri sürekli olarak doğrulayın (örn. jeolog, bu metreküp yerden çıkarıp "daha sonra" yapılana kadar tahmin modellemesini asla durdurmaz).

Tahmin edemezsen, Point sisteminin işe yaradığını söyleyebilirim . Alt yığın algoritmasına dayanan bir grup çalışmayı kabul ediyorsunuz, ancak bu mümkün olduğunca tahmin etmeye en yakın yaklaşımınız. Aslında, serbest bırakma yönetiminiz, tema (lar) etrafına uyan "backlog" kuyruğunda doğal aralar arayacaktır (örn. Silverlight'ta Ürün yöneticileri, backlog'larını tamamlayana ve başlangıçta belirlediğimiz temaları birleştirene kadar bekleyeceklerdir. mühendislik ekibinin ne yaptığını hiçbir zaman bilemezdim, sadece temel bir ana hatlarımız vardı, o zaman bu çalışma grubunu alır ve pazarlama etkinliğimizi onun etrafında yapardık (Microsoft Mix)

Hız + zamana dayanan sprint döngüleri içindeki hız beklentilerini kilitlemeye başladığınızda, sadece bu sefer daha kötü durumda olduğunuz için tahminleri tekrar geri alırsınız, çünkü “oyuna bağlıdır” oynuyorsunuz ... Daha önemlisi siz Ayrıca ekip büyümesi / kariyer büyümesi için de potansiyel öldürüyor.

Puanlar-Zaman için ödediğiniz vergi, iş yapma becerisini geliştirme / mentorluk veya geliştirici davranışını izlemek için alternatif ölçüm formülleri aramanız gereken puanlardır.

İçinde hala bir yetenek / çaba göstermek için ideal kişiniz olarak bir "medyan geliştiriciye" bakmaya ihtiyacınız olacak gibi, o zaman diğer geliştiricilere ekibiniz içinde devam eden büyümelerinde nasıl adil olduklarını belirlemek için o kişiyle temasa geçebilirsiniz. Aynı zamanda, "hızlı" geliştiricilerin suyun çoğunu taşıdığı ancak sıkılmakta ya da daha kötüye gittiği durumları vurgulamaktadır; rekabet süreleri nedeniyle daha uzun süre çalıştıkları ve hiçbir ödül / ödül almadıkları vs. “o kişi mücadele ediyor, yardım edelim” gibi, takım başına kötü kokuları tespit etmek için

Daha sonra “aktarma” hikayeleri geliyor, o sprint döngüsüne tıkanmayan ama bir sonraki sprint döngüsüne akan hikayeler. Eğer zamana faktoring yapıyorsanız, ancak göreceli zamanda faktoring yaptığınız an kolayca etkilenen bir etki yaratabilir… Ne kadar "sadece zamana dayalı tahmin / tahmin" e geri dönersiniz ve tekrar puan sistemi sadece suları çamurluyor.

Eğer noktalara gidersen, zamanı tamamen görmezden gelirsin ve tamamen zamanın içine girmesine izin verdiğin andan bahsediyorum, fikir / metodolojiyi oynuyorsun.

Bir Misyoneri olarak dünya çapında seyahat, "Ben takımların çok onlar Çevik Tahmin kodunu kırık olduğunu güldüğünü ne olursa olsun onların elini yemin gördüm ... ama hep dilimin tıklandığında, gülümsedi ve uzak düşünce ile yürüdü evet ... Sanki, ama biz 'zaman' dediğimiz metresi ... o sadece zalim ... "

Mike Cohn'un "Çevik Tahmin Etme ve Planlama" adlı kitabı, "ideal günler" veya hikaye puanları ile tahmin etmenin avantaj ve dezavantajlarını açıklamaktadır, bu nedenle sorunuzun hızlı cevabı, hikaye puanları ile tahmin etmeniz gerekmediğidir. İdeal günlerde tahmin etmek daha doğalsa, hemen devam edin.

Bence Story Point yönteminin Man-day yöntemine göre en az iki önemli avantajı olduğunu düşünüyorum: Birincisi, SP'de tahmin etmek daha kolaydır. SP görecelidir ve bizim gibi insan, insan-gün yöntemi gibi mutlak tahminden daha iyidir.

İkincisi, SP'de tahminde bulunduğunuzda "Bireysel Manday" değil "Takım SP" yi alırsınız. "Bu görev ne kadar sürecek?" Diye sorduğunuzda, Senior dev size bir Junior için 1 gün ama 5 gün verebilir. Bu Man-day, bu görevi kimin yaptıracağına bağlı. Eğer sahibi değiştirilmeye zorlanacaksa (ve olacak!) Sizin her şeyi yeniden planlamanız gerekir. SP ile, görevi kim alırsa hala aynı.

Henüz kimsenin Parkinson Yasası'ndan bahsetmediğine şaşırdım .

İş, tamamlanması için gereken zamanı dolduracak şekilde genişler.

Temel olarak, büyük işler için herhangi bir zaman biriminde tahmin ediyorsanız, geliştiriciler, tamamlamaları veya geçmeleri için tahmin ettikleri süreyi alma eğiliminde olacaktır. Öykü Puanı veya Gömlek Bedenleri gibi yoğun bir zamanda tahmin ederken, bu düşmeyi önlersiniz.

Hikaye noktası tahmini fibonacci serisi 1,2,3,5,8,13,21 ...

Bir insan beyni, boyutları temel alarak şeyleri kolayca haritalandırabilir. Örneğin: Kartpostal kartımız var ve 2 puanlı bir hikaye noktası atadık ve kart kartının büyüklüğü 2 * 3 = 6 hikaye puanı olacak şekilde üç yazı yazdık.

Öykü Noktası 6, fibonacci seri numarası 5 ve 8 arasına girerken, 5 daha yakın bir sayıya ulaşır ve bu nedenle hikaye noktası 5 olur.