Par programmering höjer inte enbart kvalitén på koden, medför automatisk kunskapsspridning samt minimerar risken för att någon osynligt kör fast…
Par programmering sänker även kostnaden för möbler och datorer, för teamet närmare och gör att fler får plats på en mindre yta.
Win! 😉
.
PairOn-stolen går att beställa här.
– ”Can be levered to standup-meeting height”
Under Agila Sverige 2010 höll Joakim Ohlrogge från Agical ett mycket uppskattat blixttal som handlar om hur vi ser på fel och hur vi hanterar dem. Titeln för blixttalen var ”Fel, fel, fel!”.
Mot slutet av sin presentation argumenterar han för att vi kanske borde betrakta och hantera fel och testning på ett radikalt annorlunda sätt…
Det hölls många intressanta, insiktsfulla och lärorika blixttal under Agila Sverige 2010. Jag var inte där själv men har fått möjlighet att kika igenom dem alla på video efteråt.
Joakims tal fokuserar kring fel, hur vi betraktar dem och hur vi hanterar dem. Dels har vi antalet fel, dels har varje fel en ”allvarlighetsgrad”. Bilden blir dock inte komplett om vi inte dessutom tar hänsyn till hur lång tid felet existerar. En litet fel som existerar under en lång tid kan göra större skada än ett kortvarigt allvarligt fel. Det riskerar sluta i irritaion, frustration, färre användare, färre sålda produkter, osv. Med andra ord…
Felyta = allvarlighet x tid.
Den totala felytan kan då minskas på tre olika sätt:
Han argumenterar för att om vi kan agera snabbt och reparera fel fort kanske vi inte behöver vara lika rädda för att ”släppa igenom” fel. Även om felet är allvarligt blir felytan liten om felen bara existerar en kort stund.
Felytan för ett mindre allvarligt fel kan vara större än för ett kritiskt…
.
Om man godtar felyta som vårt mätetal och som en mer sann beskrivning (för systemets kvalité ur ett defekt-perspektiv) fullt ut får det stora konsekvenser för vår testprocess.
Att minska antalet fel som slinker igenom och felens allvarlighet med en allt rigorösare testprocess är både kostsamt och tidskrävande, och gör dessutom inget för att dra ner livslängden på de fel som faktiskt hittas. Det kan till och med vara kontraproduktivt, en tung testprocess kan göra så att våra fel lever längre innan de blir åtgärdade.
Om vi istället fokuserar på processen (dvs. att höja kvalitén genom test driven development, par programmering, continuous integration, m.m.) och att möjliggöra snabba fixar (genom t.ex. defensiv programmering, defect proofing, rigorös loggning, etc.) samt att stöda snabba deployer av nya versioner som metoder för att minska felytan kan detta visa sig vara både betydligt effektivare och betydligt billigare.
Kan det vara så att det absolut effektivaste är att inte ha något testning alls? Hmm…
.
Joakim Ohlrogge är konsult på Agical AB.
Hans blogg heter ”The Point is Missed”.
.
.
Videoupptagningar från Agila Sverige 2010 hittar du här:
http://www.webbtv.nu/5557.htmFör att se ”Fel, fel, fel!” klicka på ”Celsius 20100510”.
När videon väl har laddats klicka på sista passet ”Fel, fel, fel!”.
Bakom Agiles princip ”The sponsors, developers, and users should be able to maintain a constant pace indefinitely” döljer sig mycket visdom.
.
Blir varje sprint stressad kommer snart vissa bränna ut sig, andra tröttnar på att anstränga sig och troligtvis kommer teamet så småningom att hitta ”hemliga” sätt att hantera detta på för att få en drägligare tillvaro. Detta i sin tur leder till att teamet kommer att prestera olika mycket varje sprint. Förutsägbarheten (och förmågan att planera framåt) och kvalitén undermineras och saboteras.
 |
”Om du alltid spurtar så joggar du i själva verket bara!” |
Vidare ges ofta rådet att ha en paus mellan två sprintar, så kallad ”Slack Time”, dvs. ha inte Sprint demo på förmiddagen och Sprint planeringen på eftermiddagen. Ge teamet en chans att återhämta sig och vila upp sig. Både produktägare och teamet kan dessutom behöva en liten stund att fundera och smälta feedbacken och tankarna från Sprint demon och Sprint retrospective och för att samla sig för nästa iteration. Se till att åtminstone ha en natt eller en helg emellan.
.
Det kanske mest kontra-intuitiva rådet är att inte enbart ha en naturlig paus (som t.ex. en helg) mellan två sprintar, utan en eller två fria arbetsdagar under vilka teammedlemmarna får ägna sig åt precis vad de vill. Uppmuntra självstudier, laborationer, test av nya verktyg och tekniker osv. men ställ absolut inga krav på resultat! Låt kreativiteten, nyfikenheten och det personliga intresset stå i fokus.
Men, skulle det dock dyka upp buggrapporter på det teamet nyss levererat måsta de släppa det de håller på med och återgå till arbetsbänken till dess att problemen är lösta.
.
Dessa projekt-fria dagar blir snart heliga för varje teammedlem. Teamet kommer att göra sitt yttersta för att inte riskera bli bestulna på sin ledighet!
Teamet kommer göra sitt allra bästa för att uppfinna metoder och tekniker för att bättre säkra kvalitén (genom t.ex. automatiserade tester, m.m.) och kommer att föra djupare och bättre dialoger med produktägaren, kund och beställare för att inte missförstå kraven. Ingen vill vara ”orsaken” till att resten av teamet fick avbryta sina projekt-fria dagar för att lösa ett problem man borde fångat upp under sprinten.
Jag låter det vara osagt om teamets arbete att höja kvaliten med detta grepp föds ur höjd teamkänsla eller grupptryck. Det lämnar jag öppet för diskussion…
.
.
Ursprungligen publicerad på sogeti.blogg.se
.
För mig har Pomodoro tekniken varit fantastiskt! Jag har äntligen fått både ett botemedel mot oinspiration och ett verktyg för att ta itu med de dagar som känns övermäktiga. Pomodoro funkar nästan som hypnos för mig!
Pomodoro är en teknik för att strukturerat och effektivt jobba av en att-göra lista, ett verktyg för att maximera nyttan av sin egen tid. De dagar då min att-göra lista verkar oövervinnerlig eller de dagar jag totalt saknar inspiration tar jag fram min äggklocka och kör Pomodoro. Idag är en sådan dag.
I korthet fungerar det så här:
Skriv ner dagens att-göra punkter. (Ta inte med mer än vad du tror är rimligt att du hinner med under dagen.)Några regler:
Verktyg: Papper, penna och en äggklocka.
Nu måste man inte använda en äggklocka, det fungerar bra med en vanlig klocka, en iPhone app, en Android widget eller valfri annan timer. Men det är något lätt hypnotiserande med det tickande ljudet som jag varmt rekommenderar.
.
BoktipsStaffan Nöteberg har skrivit en riktigt bra och djupgående bok om Pomodor tekniken: Pomodoro Technique Illustrated.
Den är välskriven och innehåller mängder med fina och tydliga illustrationer. Den är fylld till bredden med råd och djupgående analyser av teknikens underliggande mekanismer samt en mini-kurs i det mänskliga beteendet och hur vi ser på tid och arbete.
Kanske lite väl utsvävande emellanåt men riktigt läsvärd och den har definitivt hjälp mig hantera min tid mycket effektivare och faktiskt skapa en tillvaro med mindre stress. Ingen liten bedrift!
.
Tidigare inlägg om Pomodoro:
.
World Quality Report 2010-2011, en rapport som publicerades igår av Capgemini och HP bekräftade något som jag redan betraktade som ”kunskap” efter vad jag sett, hört, erfarit och upplevt i mitt kontaktnätverk på Sogeti och ute hos kunder, nämligen att fokuset kring Agil Testning, men även molnbaserade testtjänster, snabbt växer i mjukvaruutvecklingsbranchen.
I Sogetis pressmeddelande kan man läsa ett utdrag från rapporten:
”…kraven ökar, på både utvecklare och testare, för att skapa större effektivitet, konsekvent använda kvalitetssäkringsmetoder och öka återanvändningen av testautomatisering. Därför använder organisationer sig av allt mer agila och molnbaserade leveransmetoder för att modernisera sina applikationer.”
Man kan vidare läsa:
”Då kraven på IT-leveranser förändras, visar rapporten att även kraven på kvalitetssäkring ökar i betydelser. Morgondagens testare kommer att arbeta i mindre team som förväntas leverera användbar kod inom fyra till sex veckor. Korta deadlines och mindre team kommer sannolikt att leda till en framtid där prioriteringen av kompetensen i kvalitetssäkrings- och testteam kommer att förändrad.”
Den nya Agila Testaren?
.
Vidare presenteras också vad företag upplever som de största fördelarna med agil utveckling. Sådan statistik tycker jag alltid är spännande och intressant.
Detta är bara ytterligare en bekräftelse på att agila metoder vinner mark och att branchen kommit långt i en övergång till agila utvecklingsmetoder. Läs mer om de agila metodernas framfart i denna artikel.
Ladda hem rapporten i sin helhet här från Capgeminis hemsida. Kräver dock registrering.
I en rapport från tidigare i år framgår det att vattenfall och iterative metoder tappar mark till fördel för agila utvecklingsmetoder. Rapporten berättar att 35% använder agila utvecklingsmetoder och att 10% av dessa kör Scrum. Men i rapporten finns många fler spännande siffror.
Det här är kanske inte rykande färska nyheter eftersom rapporten publicerades i januari 2010. Men å andra sidan tycker jag det är så pass spännande att det är värt att repetera och det är säkert många som inte hört talas om den tidigare. Rapporten baserar sig på svaren från 1300 läsare till Dr. Dobb’s Journal och undersökningen genomfördes Juli till Augusti 2009.
.
I bilden ovan kan man utläsa att det är ungeför lika många som använder sig av agila utvecklingsmetoder som vattenfall och iterativa, ca 35% vardera. Vad läskigt värre är dock att de resterande 30% föredrar att inte arbeta efter någon metod alls!
Vidare trodde jag att det skulle skilja stort mellan stora och små företag med hänsyn till utvecklingsprocess. Icke. Spridningen är stor i båda fallen.
Däremot verkar det över lag vara så att teammedlemmar och chefer har gravt olika uppfattning om vilken process man kör, om det är agilt eller inte. Detta känner jag dock definitivt igen!
.
Läs hela rapporten ”Agile Development: Mainstream Adoption Has Changed Agility – Trends In Real-World Adoption Of Agile Methods” skriven av Dave West och Tom Grant, Ph.D (samt Mary Gerush och David D’Silva).
Hur vet man att investeringen i utvecklingen matchar förväntningarna? Hur håller man koll på att projektet levererar ”i tid”? Hur mäter vi att mottagarna och beställarna är nöjda? Scrum påstår sig leverera mera funktionalitet av högre kvalitet som bättre matchar förväntningar och behov. Men hur mäter man och följer upp detta? Detta är andra delen av min artikelserie om tips, trix och verktyg för att mäta det agila projekts framgång och status.
Nedan listar jag några verktyg och mätvärden användbara för projektets produktägare och styrgrupp (Meta-Scrum) för bland annat release- och resursplanering. Men som alltid ska man ställa sig frågan varför man mäter något? Vad ska statistiken användas till? För vem är mätvärdet värdefullt? Historisk statistik på ett mätvärde i sig har inget värde, det är först när vi omsätter det till kunskap, insikt och handling som det ger oss något tillbaka. Fram tills dess är insamlandet och sammanställandet waste och kanske t.o.m. kontraproduktivt. Vi riskerar att belysa fel saker och kanske luras försöka bota symptom istället för det bakomliggandet problemet.
.
Vilka effektmål/affärsmål har vi satt upp med nästa Release? Vilka verksamhetsproblem hoppas vi lösa? Kommer nästa Release nå dessa mål? Ser prognostiserad tidplan ut att hålla?
Med en Release Burndown kan man enkelt prognostisera när scoopet för releasen är klar. Release Burndownen är också ett enkelt verktyg för att anpassa release-scoopet för att nå önskat release datum. Finns tydliga mätbara effektmål kan Produktägaren också avgöra om tillräckligt många av dessa blir uppfyllda.
Release Burndownen ger en tidig indikation på hur projektet går. Produktägare och styrgrupp kan avgöra om release-scoopet ska justeras, deadline flyttas fram eller om teamet behöver förstärkas med ytterligare resurser.
.
Får vi valuta för pengarna? Är förväntad Return Of Investment (ROI) högre än sprintens kostnad? När ROI/Sprint sjunker under en viss gräns är det kanske dags att vara nöjd och avrunda projektet… eller se över Produktbackloggen, dvs. ta ett kreativt omtag och klura ut nya funktioner som kan skapa högre affärsvärde än de som ligger i produktbackloggen just nu.
Att leverera enligt Scrum ger oss möjlighet att kontinuerligt försäkra oss om att teamet jobbar på just de saker som ger mest affärsvärde. Men det är inte bara en möjlighet utan även produktägarens skyldighet att se till att just så är fallet.
Utöver själva sprintens kostnad växer förvaltnings- och driftkostnader desto större och komplexare systemet blir. Denna aspekt återspeglas inte i illustrationen intill men bör finnas med som beslutsunderlag vid releaseplanering.
.
Hög rest-ratio (dvs. ration rest-tasks från föregående sprint/sprintar kontra ny funktionalitet) kan signalera många olika saker men framförallt en oförmåga att avsluta features och efter sprint demo ha en produkt som är ”klar”, dvs. redo för paketering och leverans. Ju fler features som är ”work in progress” mellan sprintar desto mindre flexibilitet får produktägaren i sitt arbete med att prioritera produktbackloggen och desto mindre frihet över release-planeringen och större osäkerhet kring release-prognoser.
Vidare, om det alltid följer med rester från tidigare sprintar in i nästa sprint finns det en risk att man missa eventuella underliggande tekniska problem eller andra typer av hinder som gör att teamet har svårt att avsluta features. Inte nog med att produktägaren får allt mindre ”nytt” levererat per sprint, projektets sanna status blir allt svårare att utläsa.
.
Hur stor är den faktiska insatsen att driftsätta (alt. paketera produkten) efter nästa Sprint Demo? Har projektet skjutit upp tasks rörande överlämning till förvaltning, dokumentation, acceptanstest, installationsscript, etc. betyder det inte att man är redo för leverans bara för att Release Burndownen närmar sig noll.
Så länge Scrum-projektet inte levererar en potentiellt installerbar/levererbar ny version av systemet/produkten varje sprint förlorar man den kontroll och flexibilitet som Scrum utlovar.
Skjuts vissa saker upp tills det ”är dags” måste detta förankras med produktägaren (och eventuellt styrgruppen) eftersom Release Burndownen inte längre berättar hela historien. (Alternativt lyfts dessa arbetsuppgifter in i produktbackloggen och görs till en del av releasen.)
.
Agila utvecklingsmetoder hanterar risk på daglig basis naturligt genom korta feedback-cykler, dagliga möten, öppen insyn i teamets progress, ärlighet, tät dialog osv. Trots detta kan det vara en god idé att synliggöra de risker som finns och hur de förändras och hanteras under projektets gång. När projektet närmar sig release ska självklart denna risk helst nått noll.
Läs mer om Risk Burndown Chart i ett tidigare inlägg.
.
Project Success Sliders är ett enkelt men kraftfullt sätt för stakeholders och produktägaren att förmedla sina förväntningar till teamet. I projektets inledande fas defineras ett antal ”sliders” som var och en ger uttryck för hur projektets framgång kommer betygsättas och bedömas.
Hur bra (eller dåligt) stakeholders och produktägare upplever att projektet går i jämförelse med uppsatta ”kriterier” bör följas upp löpande så att projektet så ofta som möjligt får en chans till feedback och möjlighet att agera och reagera om så krävs.
.
Project Success Sliders beskrevs först av Rob Thomsett i sin bok ”Radical Project Managment”. Nyligen släppte Mountain Goat Software ett snyggt och enkelt webb-verktyg för att skapa och ställa in project sliders – ”Project Success Calculator”.
.
Detta är del 2 av 6. Läs vidare:
Om att mäta det agila projektets framgång (1/6) – Introduktion
Om att mäta det agila projektets framgång (2/6) – Resultat
Om att mäta det agila projektets framgång (3/6) – Produktivitet
Om att mäta det agila projektets framgång (4/6) – Kvalitet
Om att mäta det agila projektets framgång (5/6) – Teamets nivå
Om att mäta det agila projektets framgång (6/6) – Agera på kunskap
(Länkarna uppdateras allteftersom artiklarna publiseras.)
På den gamla goda tiden gick det enkelt att ta reda på om det går bra eller dåligt för ett projekt. Hur många procent av kravlistan har vi bockat av? Hur stora (eller små) är avvikelserna från budget och deadlines? Samma frågeställningar fungerar inte tillfredställande i det agila projektet.
Vilka verktyg och mätvärden finns till hands när man jobbar agilt?
.
I ett agilt projekt finns det såklart oftast budget och deadlines men ingen detaljerad plan eller detaljerad kravlista att mäta avvikelser från. En av anledningarna till att man jobbar agilt är för att man insett att dessa måttstockar inte berättar något om hur bra produkt eller system man har byggt. Samt kommit till insikt om att planer bara är prognoser och inte något facit.
Detta betyder dock inte att vi ska sluta bry oss om hur bra eller dåligt ett Scrum-projekt går. En agil process som välkomnar förändringar och bygger på att skapar kunskap verkar dock slingra sig från att mätas. Vi måste ta till andra metoder och mätvärden än de vi kanske är vana med för att få en bra insyn i hur projektets sanna status är.
Först och främst borde vi förtydliga vad det är vi egentligen undrar när vi ställer oss frågan om ett projekt går bra? Kanske kan frågan styckas upp i följande, mer konkreta, frågeställningar:
.
Nedan listas förslag på mätvärden som kan användas för löpande utvärdering av ett projekts framgång och status och som beslutsunderlag under den löpande planeringen. I kommande artiklar (del 2-6) kommer jag beskriva var och en djupare och förklara vad dom syftar till och vad mätvärdet kan berätta om.
.
.
Resultat
Projektets förmåga att göra stakeholders glada och leverera värdefull mjukvara enligt plan och prognoser…
.
Produktivitet
Teamets förmåga att produktivt bygga och leverera funktioner…
.
Kvalitet
Teamets förmåga att bygga kvalitativ mjukvara…
.
Teamets nivå
Mår man bra och är motiverad gör man ett bättre jobb…
.
Man får dock inte luras att tro att det finns egenvärde i något av ovanstående mätvärden! Eller än värre, ge sig i kast med att försöka sub-optimera med hänsyn till ett enskilt värde.
Alla former av suboptimeringar har en tendens att slå tillbaka och försök att belöna (eller bestraffa) team eller individer baserat på valfritt mätvärde riskerar sabotera projektet och kommer med tiden undergräva teamets effektivitet, moral och förmåga att bygga kvalitativ mjukvara.
Innan ni i ert projekt börjar föra statistik och historik fråga er varför ni mäter X, vilket problem hoppas ni kunna lösa och hur resultatet ska användas.
.
Detta är del 1 av 6. Läs vidare:
Om att mäta det agila projektets framgång (1/6) – Introduktion
Om att mäta det agila projektets framgång (2/6) – Resultat
Om att mäta det agila projektets framgång (3/6) – Produktivitet
Om att mäta det agila projektets framgång (4/6) – Kvalitet
Om att mäta det agila projektets framgång (5/6) – Teamets nivå
Om att mäta det agila projektets framgång (6/6) – Agera på kunskap
(Länkarna uppdateras allteftersom artiklarna publiseras.)
Test Driven Utveckling och par programmering är de kraftfullaste tekniker jag känner till för att höja kvaliten och minska antalet fel i koden.
Men hur kommer det sig att det smyger sig in galenskaper och fel i koden över huvud taget? Varför kan vi inte ”bara” koda rätt från början?
Som jag ser på det finns det två övergripande kategorier av fel-källor:
.
Tolkning
I alla steg när man tvingas tolka eller minnas vad det var man skulle bygga finns alltid risken att man missförstår kravet, user storyn eller problembilder. Vissa detaljer kanske man glömmer bort, andra introducerar man i felaktig krav-extrapolering.
Tankevurpor
Man tror att ett problem går att lösa på ett visst sätt, kodar utan vare sig introducera buggar, minnes läckage eller andra svagheter. När man sedan börjar testa visar det sig att man tänkt galet och att skriven kod inte alls klarar av att lösa problemet eller beter sig inte som man föreställde sig när koden skrevs.
.
Okunskap
När man anropar funktioner och integrerar mot moduler som andra har skrivit gör man det ofta utan att förstå den koden ordentligt, dess krav på input-parametrar, etc.
Stress
Press och stress kan ibland kortsiktigt höja fokus och prestation, men efter en stund vänds effekten och man börjar missa detaljer och introducera slarvfel, eller helt missa koda vitala delar i sin flykt undan piskan.
Tristess
Är du uttråkad och totalt oinspirerad är det till och med ansträngande att göra ett hyffsat jobb. Man lockas till genvägar och snabb-hack.
Trötthet
Jobbat för mycket övertid? Svårt att sova? Är man trött går allt lite långsammare och ibland känns det som om kablarna i huvudet inte riktigt når hela vägen fram…
Repetition
Som människa är man inte speciellt duktig på att upprepa något monotomt många gånger utan variation.
Avbrott
Avbrott gör att man tappar fokus och kanske tar upp arbetet lite vid sidan av där man slutade.
Rädsla
Är vi rädda för att få skäll, blotta vår okunskap eller förmedla dåliga nyheter har vi en tendens att prata mindre, skydda oss från dålig feedback och slutar ställa frågor. I värsta fall börjar vi trevande gissa sig fram på egen hand utan att egentligen veta om vi gör rätt eller fel.
Klantigheter
Copy’N Paste slarv. Syntaxfel. Tangent-glidningar.
.
Finns det metoder och tekniker som fullständigt eliminerar ovanstående källor och orsaker? Antagligen inte. Men som jag skrev inledningsvis är TDD och par programmering de kraftfullaste teknikerna jag känner till.
Sedan har jag idéer, synpunkter och erfarenhet kring andra tekniska tekniker och mjuka metoder för att förebygga och skydda sig mot fel. Dessa finns det dock inte utrymme att skriva om här idag, och jag känner dessutom att de förtjänar en egen artikel.
.
Äldre relaterade inlägg:
Dagens sprintplanering är precis avklarad. Lite bökigare än vanligt eftersom våra sprintmål denna sprint var väldigt spretiga men vi nådde i land till slut. Spretiga sprintmål riskerar sluta i att det blir svårt att fokusera och samlat och disciplinerat jobba mot en sprint demo. Dock borde vi kunna hålla bra koll på våra framsteg med hjälp av JIRA och vår dagliga Sprint Burndown, verktyg som vi blir allt bättre på att använda och utnyttja.
Då teamet sitter distribuerat har vi inga daglig Stand-Up Meeting utan kör istället med ”Daily Call-Up”. Strax innan telefonkonferensen mötet skickar jag också ut en fräsch och uppdaterad Burndown-chart för att vi ska kunna lyfta blicken och inte bara fokusera på ”här och nu”. Bäst hade såklart varit att träffas fysisk IRL runt en vägg med sprint planeringen och flytta runt på lappar istället för att uppdatera tasks i JIRA, men men, vi arbetar kontinuerligt med att göra det bästa av situationen.
Vår Sprint Burndown är absolut ingen rocket-sciense men tänkte att det alltid är någon som uppskattar att se exempel från verkligheten. Denna screenshot är några veckor gammal men passar ändå bra som exempel.
(Klicka på bilden för att se en större version)
.
Utöver att spåra återstående tid har vi längs med resan lagt till ytterligare dimensioner på vår burndown (information som extraheras från JIRA). Alla värden och estimat i tabellen ovan är i timmar.
Total – Summan av orginal-estimeringar för alla tasks. Vissa sprintar ”uppstår” arbete när vi lär oss mer om de tekniska utmaningarna. Ibland stryks detaljer funktioner (pga av det antingen blir inaktuellt att implementera dem eller för att de scoopas ut från sprinten). Vi har lärt oss att vår velocity ligger på ungefär 3,5 – 4,5 per dag och teammedlem och det är vi planerar efter.
Remaining – Återstående arbete, dvs. summan av uppskattad återstående tid (Remaining Estimate) för alla tasks som inte är ”Resolved”.
DONE – Avklarat arbete. När en tasks går från ”In Progress” till ”Resolved” ökar DONE med taskens ursprungliga estimat.
In Work – Original estimate summeras för de tasks som är ”In Progress” just nu. Denna försöker jag hålla så låg som möjligt så att det inte jobbas på för mycket parallellt.
.
Det jag saknar och eventuellt överväger att lägga till är:
Added/Removed Work – Möjlighet att se hur mycket arbete som läggs till eller tas bort under sprintens gång. Just nu ser vi bara hur totalen växer och minskar. Om en task tas bort och en annan läggs till syns ingen skillnad i grafen.
Jimmy Janlén "Den Scrummande Konsulten" 