35. Jag hör vad ni säger men förstår inte
lyssna! 
Sommaren är (snart) över och vi snackar därför planering. Planering av sprintar, features, kapacitet, SAFe och mycket annat. Hur ska man väga tiden spenderad på planering mot tiden sparad, att grotta ner sig lite för mycket, hur våra drömplaneringar ser ut och vad vi tycker om estimering. Dessutom en hel del om hur generell och specifik erfarenhet påverkar resultatet.
Om du gillar podden blir vi väldigt glada för en liten recension i iTunes eller en prenumeration på Spotify. Följ oss och säg hej på @asdfpodden på Instagram eller Twitter (Anton, Therése) <3
Avsnittets skämt:
Varför var programmeraren så dålig på tennis?
Fick inte ordning på serve(r)n.
Skrapa här!!
Transkribering
Transkriberingen är gjord av nån "AI-grej". Du kan förbättra den genom
att klicka precis här :) Varför var programmeraren så dålig på tennis?
Jag vet inte.
Fick inte ordning på servern?
Det var ju bra!
Du blev inspirerad av OS.
Ja, det förstår jag. Det var bästa på länge.
Det går uppåt igen, känner jag.
Nej!
Jo, jag tyckte det var bra.
Säger mer om dig än om skämtet tror jag.
Ja, så kan det mycket väl vara faktiskt.
Men välkomna till ett nytt avsnitt av ASTF.
Ja, välkommen.
Man ska inte säga, jag är lite ringrostig känner jag.
För det var ändå ett tag sedan vi spelade in ett antal avsnitt innan sommaren.
Som sedan har portionerats ut.
Men man känns ändå lite ringrostig och så snackar jag in en mikrofon igen.
Ja, det var ett tag sedan får jag ändå säga.
Jag hade kanske låg energi innan sommaren. Jag är fortfarande kvar i samma mode.
Så vi får se hur det går.
Men efter semester och sådana saker, alla fall speciellt för dig, så tänkte vi att vi kanske skulle kunna fundera lite på
vad vi tycker om planning och vad vi tycker funkar bra med planning och så vidare inför hösten.
Och kommande kanske roadmaps och annat skoj.
- Ja, precis. Och det passar väldigt bra. Nu tycker jag att hos den kunden jag sitter hos så ska vi köra några planeringsdagar om en vecka eller två.
För vi kör SAFE, alltså Scaled Agile Framework. Eller en variant på det i alla fall.
Då ingår det där att man kör något som heter PI-planering.
Och PI står väl för Project Iteration, och det är en samling med sprinter.
SAFE är ju ett mega ramverk som innehåller hur många delar som helst.
Men då kör man ju de här planeringsdagarna.
Så då planerar vi typ tio veckor framåt, vad som ska göras.
Och grovplanerar de sprintarna som ingår i den perioden.
Och sen kör vi då planning för varje sprint också, när man startar dem.
För att bryta ner allting till olika mindre bitar och estimera det och sånt.
Men det kommer upp snart. Så jag är lite nyfiken på vad du tänker om planning.
För jag vet att det finns ju ändå lite olika skolor, tänker jag.
Oj, vad tänker jag om planning? Alltså jag har ju inte planerat på ett tag nu av lite orsaker.
Men jag tror att om jag liksom tänker tillbaka på alla planning som har genomförts,
Jag tycker att det överlag är väldigt svårt att få till en bra planning.
Jag vet inte om det känns som att jag någonsin knäckte nöten.
Dels pratar man mycket om estimering och estimerar man så är det överlag svårt.
Det är ofta oförutsedda saker som dyker upp och det kan vara problem som blir mycket svårare än som förutsett.
eller det kan komma in saker från sidan, akuta buggar, beroende från andra team och så vidare.
Så det är ofta svårt att förutse och så har man ju olika formler för det såklart.
Och liksom, när man räknar bort att folk inte är heldaga för möten och vab och sådana saker.
Så att man kan ju verkligen beräkna det, men jag tycker ju sällan att det håller.
Så att, ja, man behöver ju en planning.
Jag vet inte vart jag vill med den här räntan.
Mitt ärligaste svar är väl att det är svårt.
Och det är det enda jag har nu.
- Ja, jag håller verkligen med.
Jag tror att det finns lite olika perspektiv.
För att det är en grej att planera ett Greenfield-projekt.
Om vi ska bygga någonting från grunden.
Vi ska bara bygga nya features, vi ska bara göra det här och sen ska vi releasa det.
Och då är det en sak att planera för då kan man säga "ja, vi gör det här, det här och det här".
Men verkligheten är ju ofta att du underhåller ett system samtidigt som man bygger något nytt.
Eller man bygger vidare på något, eller man gör många olika saker samtidigt.
Och det som jag tror är det största problemet som jag upplever är att man måste planera allting i relation till varann.
Alltså så här, oj här kom det in lite buggar som det måste vi fixa.
Oj här kraschade systemet, någonting gick ner så vi måste fixa det här.
Oj här gick en deploy pipeline sönder och då måste vi fixa det här.
Så det är så mycket delar som är så svårplanerade och inte bara svårplanerade utan även svåra att tänka på när man planerar.
Som jag tycker gör det så sjukt svårt att få en bra bild av hur lång tid saker kommer ta.
Ja, fast det där tycker jag är nästan samma sak för Greenfield också. Om ingenting är releaseat så kanske man inte har de bitarna.
Men helt plötsligt blir det så här, vi ska bygga det här. Ja okej, men det kommer ju bero på det här. Ja just det, men det har vi inte än.
Så det måste vi bygga, eller det här problemet måste vi lösa. Alltså det är många oförutsedda där med tycker jag.
Jo, det har du ju väldigt rätt i. Jag tror kanske att det upplever även att det är mer sånt när man har system som ligger live.
eller man har flera system som man underhåller, eller liksom där man har en större systemflora för att använda ett ord jag inte har använt på väldigt länge.
- Ja, det där håller jag med dig.
Men det är också mycket för att man ska kunna se saker. Dels är det svårt att planera saker som man inte har förutsett.
Det är svårt att planera saker ordentligt om man inte går till botten med vad det är som ska planeras.
För den där tycker jag är skillnaden på, man kan sitta överskådligt och gå igenom tickets.
Det här ska vi göra, det här ska vi göra, det här ska vi göra.
Och alla kan sitta där och gissa hur lång tid det kommer ta och vad som ska göras.
Men det som jag tycker ofta krävs för att få till en riktigt bra planering,
det är ju att verkligen ta ticket för ticket och gräva.
Vad finns det för krav? Vad finns det för kriterier?
Vad är det vi vill göra med det här?
Vad har vi för beroenden till det?
Vad kan tänkas komma upp där?
Problemet är att det tar så himla lång tid,
samt att det kan finnas en halva av teamet som inte alls är engagerade eller involverade.
Så det kan bli extremt tradigt förresten.
Men jag tycker ofta att det är det som krävs för att få det så bra som möjligt.
– Ja, det känns alltid som att det är en avvägning mellan att vi ska bara estimera den här så snabbt som möjligt på ett väldigt grovt sätt jämfört med att som du är inne på, gräva ner sig, se till att man vet vad fallgroparna är och vilka risker som finns och sedan estimera utifrån det.
Det känns som att det är den avvägningen som avgör hur bra estimatet blir, men också hur mycket tid det tar att göra.
- Ja, och sen är det också frågan om vilka som ska vara involverade. Kan man dela upp det i olika skeden då?
För många kör ju kanske grooming, på tal om att vi har pratat om ord man kanske inte vill använda, men grooming innan planning.
Och det kan ju ofta vara hjälpsamt om det funkar.
Alltså det kan ju ofta vara så att det tar upp en individ
eller liksom två individers tid, en utvecklares tid
som har väldigt bra koll och kan översiktligt ge en
"Det här tror jag funkar, det här kan vi dra in, det här kan vi inte"
och sen kan teamet planera det tillsammans liksom
så att inte alla behöver vara med samtidigt.
För jag har varit på planings, där vi liksom har varit väldigt uppdelade
så att man har frontend och backend, olika personer.
Det blev väldigt mycket så att man kunde fastna väldigt mycket på frontend-tickets och då checkade backenderna ut, vilket jag förstår till fullo.
För att det är ganska tradigt att sitta och lyssna på saker som inte alls berör en eller det man håller på med.
Och så vice versa. Det hoppade med att hälften var alerta, men allas tid gick åt till att sitta på det.
Ja, precis. En grej när du sa grooming som jag tänkte på. Jag tror att du faktiskt officiellt har bytt namn till Refinement.
Har jag för mig. Så det är i alla fall ett framsteg.
Ja, det är nice. Jag kom inte på den termen. Den har jag ju hört. Men låt oss försöka hålla oss till den.
Det är väldigt lätt som du säger, om inte hela teamet är inblandade i allt så blir det ofta att
"nu kommer vi till den här ticketen, då är det en viss person som har koll och då ska den personen
undersöka litegrann" eller en grupp av personen ska undersöka.
Men jag vet inte, jag tror att för mig är nog den lösningen att alla borde vara med på allt ändå
bara för att man ska kunna lära sig och ska kunna sitta med både fronten och backen.
För jag tycker oftast att det är det bästa sättet att jobba på. Även om man kanske inte behöver vara specialiserad.
Som vi var in på. Man kanske är specialist på back-end eller front-end.
Men att man ändå kan göra saker i båda så att säga.
Men om man ignorerar det perspektivet så håller jag med dig om att det är extremt lätt.
Även om man är så, så är det lätt att säga "Ja, men den här kan inte jag någonting om, så jag zonar ut"
Och så sitter tiden och går och tickar klockan på liksom
Och det är en ganska stor utmaning. Jag sitter ju delvis som Scrum Master nu i mitt team
Och då har jag ansvar för den här planeringsdagen, att vi ska kunna planera allting som ska planeras och allting sånt
Och där är det ju alltid en utmaning att
Kan vi titta på den här saken nu och så börjar folk verkligen grotta ner sig och gå på djupet som du är inne på.
Så att vi kommer få ett jävligt bra estimat.
Men samtidigt så går det då extremt mycket tid.
Och jag vet att vi har de här två dagarna på oss.
Och det är under den tiden som vi ska hinna med alla grejer som ska estimeras.
Och då måste man till slut säga, tyvärr hörni, nu hinner vi inte kolla mer.
Men kan vi ta ett grovt estimat?
Och då kanske estimatet blir lite sämre.
Och sen spar man lite tid åt de som inte gräver ner sig.
Ja, det är bra att ha den insikten att nu kan vi stoppa här och så får vi göra det här.
För jag tycker det är ofta att man ser någon, kanske produktägare eller så, sitta och svettas nästan hela tiden har gått.
Men man bara är en tick fram.
Exakt, problemet är väl att jag är med i den här gruppen som gräver ner sig.
Jag bara, nej jag vill titta jättedjup på den här grejen.
[Skratt]
[Skratt]
- Ja, men alltså det är ju så man hittar de oförutsedda.
Det går ju inte att lösa allting, men det är där man får den som mesta informationen.
- Ja, nämen exakt.
Nej, jag tycker det är skitsvårt.
Och sen även om man gräver ner sig djupt i saker så tycker jag ofta att det är extremt svårt att estimera.
Jag är väldigt mycket för att inte estimera alls.
Eller kanske säga att man tittar på några artiklar och bara "vad har vi för en känsla att vi hinner med?"
Och så kommunicerar man "ja men vi hinner med de här fyra på de här två veckorna"
Eller vad man nu kör.
Och inte estimera någonting mer än så.
Men problemet med det blir ju fortfarande när man går uppåt i hierarkin.
i hierarkin, för det är ofta därifrån de här kraven kommer, att det är någon
människa i företaget som behöver veta "Okej, men när kan jag kommunicera att den här
grejen kommer ut?" eller liknande. "När kan jag planera det där?"
Och man måste synka med andra team att säga "Vi kommer hinna klart med den här
biten som ni beror på på den här tiden." Samtidigt tycker jag att många av de här
problemen löser sig av att man kommunicerar med varandra och säger,
Att folk ställer frågor och man kommunicerar och säger "Vi har inte hunnit på det med den än, det borde vara ungefär så här lång tid kvar".
Och att man slipper de här exakta estimaten på "Vad tror vi, hur många timmar tar det här?"
Eller hur många story points tar det här som ändå alltid blir timmar i ens huvud när man estimerar.
Så jag vet inte, jag tycker det är svårt.
Men sen finns det ju, jag vet inte, har du kört så här typ planning poker till exempel?
Ja, några få gånger. Jag håller ju med dig om att det här med estimering är, det känns jobbigt. Samtidigt har jag aldrig varit en person som suttit och svettats framför en styrgrupp och ska förklara vart projektet är på väg och hur lång tid och hur mycket resurser och budget som behöver.
Jag kan bara känna mig glad över att jag inte har den rollen.
Så jag förstår ju som du säger också varför det behövs.
Men jag tror, just den där som du säger, att det kommer alltid ner i timmar på något sätt.
Så blir det ju i huvudet.
Men jag har kört planning poker några få sporadiska gånger.
Och jag tycker ändå att det är ganska trevligt.
Man går igenom det här lite och sen så tänker alla för sig då allt, liksom.
Och så vänder man upp det och så diffar det mycket så får man ta diskussionen där.
Då blir det ändå på något sätt att jag för mig själv har försökt få skapa en uppfattning utan att någon var först.
Och sen så hakar det jag bara på, liksom.
Vad pågår i mitt huvud där och de andras huvud?
Och så känns det ändå som att man har en tydlig diskussion där alla kanske får rum att lyfta sina tankar.
Ja, precis. På samma sätt som att köra en runda när man sitter i ett möte och frågar "Vad tycker du? Vad tycker du? Vad tycker du?"
Så är ju planningpoker också ganska inkluderande i att det öppnar upp möjligheten för alla att säga sin åsikt.
Sen finns det såklart negativa tankar med det. Om man är oerfaren, att man inte vågar gissa eller vågar att det blir en obekväm situation.
Men det är mer kanske en team-känsla-grej än något annat.
Men jag håller med att det finns ju definitivt fördelar med att göra det.
Och jag tycker att om man ska sätta ordentliga estimat, eller om man ska sätta verkligen på varje nivå, eller om man har story points eller timmar, eller vad man nu kör.
Då tycker jag ändå att det är ett vettigt sätt att göra det på.
Ja.
Jag tycker också egentligen det är rätt skönt att kapa det här med timmar.
Just att vi körde någon gång, om det var poäng eller t-shirt sizes eller vad det var.
Och att den minsta estimeringen, små eller en poäng, det var en dag.
Det gick inte att få det mindre än en dag.
Visst att vi kunde ha så här buggar och saker som var "det här tar två timmar".
"Ja men det skiter vi i, vi sätter bara den minsta estimeringen på det och sen så går vi bara uppåt därifrån."
Så att man tänkte i fulla dagar.
Och det kände jag ändå var okej.
Där brukar man ändå kunna vara hyfsat nära på hur lång tid det ska ta.
Speciellt om man lyckas bryta ner det.
Ja, men precis. När vi estimerar nu över tiden, det är också lite så här hip-hop-hopp hur vi gör, men på sistone har vi också kört att vi sitter och diskuterar saker och sen bara "ja men ska vi sätta någon tid på det här?"
Sen kör vi inte riktigt planning på det, utan det är mer att folk slänger ut sig i saker och så får man hålla med eller inte.
Men det beror också på att vi är ett väldigt litet team och ganska inkörda.
Men vi kör i dagar just.
Och säger att den här tar nog en dag.
Och jag tror att en dag brukar vara det minsta vi sätter också.
Ibland kanske det har hänt att vi har satt en halv dag bara för att man vet
att jag vet vad som ska göras, det här är en rad kodändring
och sen så är det bara att pusha.
Och då kanske man sätter en halv dag.
Men annars är det typ en dag brukar vara det lägsta vi sätter.
Och då har vi också räknat ut lite halvt innan vad vi har för kapacitet, alltså det vill säga hur många arbetsdagar vi har i teamet, eller utvecklade dagar
Så att vi har det i bakgrunden också, och sen används det som en jämförelse på, har vi plats för mer att trycka in här?
Och det är just för att vi estimerar grovt för att få en uppfattning om, okej hinner vi det här på, jag vet inte vad det nu är, 10 veckor?
Sen gör man det lite annorlunda när man kör själva detaljplaneringen.
Man går in på varje och bryter ner den och sätter upp den till olika och då kanske dagestimaten spricker eller så blir de bra.
Men det är ett väldigt skönt sätt att göra det på för att få det grova estimatet.
- Sammankollat, hur många möten har du och när är du borta de här dagarna?
Ja, det blir nice och så har vi fått upp så här många timmar så går någon jävel och blir sjuk.
- Exakt, och så spricker allt.
Vi brukar köra det och sen har vi ändå historiskt lite känsla av hur mycket det brukar bli i verkligheten.
Även om man jobbar åtta timmar per dag eller tio dagar under den här sprinten.
Då kanske vi vet att i verkligheten blir det sju och en halv dag för den här personen.
För att du har mycket möten och annat.
Så vi brukar ofta anpassa det så.
Och det funkar ändå okej tycker jag.
Men sen gäller det fortfarande att vara flexibel med sin planering.
Alltså det är inte så att man sätter sin sprint-backlag och sen bara "ja, nu kan vi inte förändra den här ett dugg".
Utan man måste ändå vara med på att "okej, antingen kanske vi måste dra in mer grejer om vi har lagt för lite"
eller så måste vi vara beredda på att saker kommer spilla över för att vi inte hinner klart med dem.
Ja, men en riktigt gedigen planering lägger också en mycket bättre grund.
För annars kan det ofta vara så att man gjorde en ticket och så bara "ja, så estimerar vi den"
när man faktiskt ska gå in och göra den några dagar senare.
Om man inte haft den gedigna genomgången kring det, då dyker det upp en massa frågor
som man inte fattade att man hade när man bara tittade snabbt på den.
Och då blir det helt plötsligt att man måste jaga tag i produktägare eller andra utvecklare
för att samla mera information.
Och det kan man ju ändå komma ifrån om man verkligen har gjort det här grundjobbet innan.
Ja, verkligen. För det är ett superbra tillfälle att ställa de här frågorna.
Eller bara ställa frågan till teamet. Har vi vad vi behöver för att börja utveckla den här?
Alltså vet alla vad den går ut på? Vet vi om vi har något beroende till andra team eller system?
Eller vad det nu kan vara? Det är liksom ett perfekt tillfälle, och det är väl lite till för det,
att man ska kunna reda ut sådana frågor så att när man väl sätter igång, då kan man bara köra.
- Ja, sen blir jag imponerad av folk som är riktigt bra på planering också.
För jag är verkligen inte det. Jag är notoriskt dålig på att bryta ner saker.
För det känns också lite som nyckeln till en riktigt bra planering och estimering.
Det är att du kan få ut tydliga, mindre uppgifter från en stor.
Jag ser en stor och så blir jag så här... [skratt]
Och sen så går jag in i nåt typ av lite... "ha, ha" och så börjar jag bara dra i ett hörn.
Och så får jag se vad som kommer ut av det. Det funkar bra för mig, men det funkar inte så bra för planering.
Det här är lite flashback till något väldigt tidigt avsnitt vi hade i poddens historia.
När du pratade om att du typ fel sökte saker som bara drar i ett garn nyss och ser vad som dök upp.
Ja men lite så är det. Det är min mentala bild av allt. Jag får bara dra och hoppas att det löser sig.
Exakt. Jag tror ändå att jag är hyfsat duktig om man får säga det om sig själv, att bryta ner.
Men ibland är det svårt för det handlar mycket om den kunskapen man har.
Om jag har en väldigt djup förståelse för hur ett system fungerar, eller hur den här delen av systemet fungerar,
så är det ju så mycket enklare att säga, ja men då vet jag att det kommer beröra de här bitarna, den, den, den, den.
Och sen tänka, ja men vi kommer behöva design på det här, vi kommer behöva det här och det här och det här.
Och det är ju så mycket enklare när man liksom har kommit in i ett system än precis när man börjar.
Alltså jag vet att när jag började hos Gunniga just nu, man var så här, ja ni pratar om saker, jag hör att ni säger ord,
men jag förstår inte så mycket. Men jag sitter där, rickar och säger, ja absolut, det låter bra.
Jäntjänighetsfaktorn är hög nu.
Det är sant när du säger det så, ju mer information man har desto tydligare blir det att se det.
Men just där i början eller när man är i någon slags mellanläge eller ska ut i något nytt område, det är svårt.
Ja, verkligen. Just den här planeringsbiten.
Det krävs mycket mer av den här djupdykningen som vi pratade om.
För att kunna få ett bra estimat, mindre förståelse.
Alltså, du har en fullt system. Desto mer måste man djupdyka för att kunna uppskatta hur lång tid saker tar.
För det kommer mycket med erfarenheten och att kunna estimera saker.
Visst, jag kan ta med mig erfarenhet från en tidigare eller ny kund och uppskatta.
Vi har byggt ungefär samma sak och det kan hjälpa till.
Men samtidigt finns det så mycket egenheter med alla system som gör att det är extremt svårt att generalisera ett estimat på olika delar av systemet.
Eller olika system eller vad det nu kan vara.
Ja, så är det ju verkligen. Man har byggt det lite annorlunda och så kommer det in de här grejerna.
Har man lagt ett CMS där det inte var förut och så vidare.
Det finns många fällor.
Ja, precis. Jag tycker det är svårt.
Men ja, har vi någon sammanfattning kring vad vi tycker är bra planning?
Om man ska drömma, då är min planning oftast rätt obefintlig.
Jag vill absolut helst jobba med att man tar nästa grej i backloggen.
Du går uppifrån och ner och så har du en priorordning på saker.
Jag är helt med på argumentet att för att kunna prioritera måste du veta hur stora de är för att kunna väga dem mot varandra.
Men om man ska drömma så tycker jag att en backlog i priorordning där man inte behöver estimera
Eller man kan grovestimera och säga att den här kommer ta en månad och den här kommer ta en dag kanske.
Men bara en backlog där man plockar saker och man inte behöver planera så mycket av att man har sprintar eller man har det här och det här och det här
Man kör bara och sen så "releasar" man hela tiden.
Man "releasar" inte efter sprintens slut utan man kör på tills hela tiden.
Det är ju liksom drömmen. Min drömplanning är liksom ingen planning.
Men din dröm är lite kanban?
Ja, jag är lite åt det hållet absolut.
Men det är också lite kombinerat med "no estimates"-rörelsen.
Sen kommer det in en massa andra delar i det här också.
Att man ska mobbprogrammera och fan vet allt.
Men det är lite orelevant.
- För just den här diskussionen. - Ja, men det är det ju inte.
Drömmen vore ju att när man plockar den här ticketen från början,
när man bara plockar den och vi ska börja rota i den,
då skulle drömmen vara att ha alla intressenter samlade.
- Mm, ja, absolut. - Och gå igenom den där och då.
- Absolut, det håller jag med om.
Eller att den är extremt väl förberedd redan,
av någon magisk liten tomte som sitter och förbereder tickets åt en.
Precis, som kan alla delarna, men inte jobbar med alla delarna.
Exakt.
För det är ju det också när man säger såhär, den här artikeln har alldeles för lite information.
Men det är ju jättesvårt för folk att veta det.
Det vet man ju själv om jag ska försöka skriva någonting på ett bra sätt, objektivt för folk som inte är i min roll.
Man missar ju hur mycket som helst, eller även ett språk som inte alls är något som folk som inte jobbar i samma roll tycker är lättförståeligt.
Det är jättesvårt att fastna. Jag förstår verkligen varför ingen bara kan göra den mest fulländade "the golden ticket".
Ja, nej exakt. Jag tycker det är svårt. Men ska man vara lite mer realistisk än en superdrömmare så tänker jag ändå att ticketsen är hyfsat förberedda redan.
Det finns kanske någon kravspecialist eller något, vad man nu kallar sådana folk nu för tiden, som har preppat ganska mycket så att kraven i sig är väldigt tydliga.
Men sen kanske inte det tekniska så tydligt än.
Men sen att man sitter och, som du säger, alla intressenter finns på plats.
Så att man kan diskutera det här och att man kan ta en bit i taget.
Sen kanske, jag vet inte, lagom mycket tid för att gräva ner sig.
Eller att den är så pass flexibel.
Det beror ju på när man gör planingen också.
Gör man planingen samma dag som sprinten börjar, då blir det svårt.
Gör man planingen en vecka innan, då har man ju ändå lite marginal att säga så här
"Vänta, vi kan kolla på den här så kan vi se lite mer. Jag kan ta en timme och sitta själv och gräva lite."
Så det kanske också är en vinstfaktor, skulle jag tro.
Jag är nog ändå för att ha en refinement med kanske en utvecklare som har väldigt bra koll.
Och då behöver det inte vara så att de ska sitta och gräva utan det är snarare om någon undrar
"Ja, men den här ticketen mot den här ticketen, vilken kommer ta längst tid?"
Och så kan den bara svara med sin införarenhet att det kommer vara den där.
Och sen så är det någonting som behövs undersökas tydligare.
Då kan den utvecklaren ta med det till resten av teamet.
Så kan man välja någon som sitter en timme med det, som har bra insikt och sådär.
Så att det ska vara lite rapt.
Och det tycker jag ändå brukar ge mer.
För att det är också svårare tycker jag.
Det beror såklart på team.
Men det är alltid svårare tycker jag att få folk att svara i grupp.
Ja, absolut.
Det håller jag med om.
För sitter du som ensam utvecklare där, ja men du kanske har fel men det gör inte så mycket, men ni hade tankar där och då. Men sitter man i en hel grupp, det blir så mycket mer att "steak" på något sätt.
Att det kostar mer att lyfta tankarna då.
Ja, precis. Och det är väl som sagt, som vi var inne på lite med planningpoker också, att det hjälper ju också mot sådant paralys. Eller vad man ska kalla det.
Jag har nog aldrig riktigt kört en sån här superplanning och verkligen använt verktygen sånna här burn down charts och grejer i Jira.
Jag tror jag hade någon period där vi satt i team och den alltid såg fjäklig ut för att jag hade estimerat fel.
Jag har nog faktiskt aldrig testat en sån här superstrukturerad och använt alla verktyg som finns, så det kan jag egentligen inte säga någonting om.
Det kanske är det som är guld.
Jag har ändå gjort det.
Jag har tittat på Burndowncharten varje stand-up.
Det var inte så nice.
Ja, men då kanske vi ska avsluta där.
Absolut.
Vi kanske inte kommer med super mycket lösningar.
Men mycket tankar.
Det är vanligt att vi är så kallade "tyckare".
Väldigt mycket tyckare, absolut.
Men det får man fan vara när man poddar.
Det är där poddar är till för.
Ja, ta absolut ingenting du säger någonsin för sanning.
Men det tänker jag att ingen gör så delvis.
Ja, det är det.
Men med det sagt så tackar vi för oss.
Finns som vanligt på sociala medier.
Eller vad säger jag? Men Twitter i alla fall.
Och länkar ligger i beskrivningen.
Recensera oss gärna på iTunes.
Det tycker jag är nice om ni gör.
om ni gör. Bli glad! Vi säger så. Det gör vi. Bye bye. Hejdå!
(Musik)
[Musik spelas]
Hej!
