Hvis du arbejder indenfor IT og har gjort det i mere end 5 \u00e5r, er du formentlig enten en af dem der selv arbejder med at estimere (p\u00e5 andres foranledning), eller g\u00f8r hvad du kan for at skubbe det med at estimere over p\u00e5 en andens bord. Sidste mulighed er at du tilh\u00f8rer den heldigvis voksende gruppe der har set styrken i at estimere relativt \u2013 og specielt, den v\u00e6rdi det bringer med sig.<\/p>\n
Hvorfor skal lige netop JEG estimere<\/strong><\/h4>\nDet er der mange gode grunde til.<\/p>\n
\n- Der er nogen der har bedt dig om det. Og de kender dem der udbetaler din l\u00f8n, s\u00e5 det er nok i bund og grund en god id\u00e9<\/li>\n
- Det kan v\u00e6re du er chef for nogen, og beder om estimater fra andre s\u00e5 du kan skabe overblikket. Der sker typisk det at du alligevel skal estimere \u201ddet der ikke kom estimater for\u201d, uanset hvad grunden til det m\u00e5tte v\u00e6re.<\/li>\n
- Du er en del af et agile team og udf\u00f8rer hyppigt relativ estimering p\u00e5 ganske kort tid, <\/em>og anvender disse estimater til at prognosticere dette og kommende sprint udfald.<\/li>\n
- Du er en del af et agile team, og estimerer overhovedet ikke<\/em>! P\u00e5 trods at dette er du stadig i stand til at forudsige dette om kommende sprints udfald.<\/li>\n<\/ul>\n
Hvad skal estimater bruges til<\/strong><\/h4>\nHelt generelt bruges estimater til at forudsige noget p\u00e5 kortere eller l\u00e6ngere sigt. Men helt \u00e6rligt, hvorn\u00e5r har du sidst set en langsigtet prognose der rent faktisk ramte bulls eye? Det sker, bevares. Men mener du frekvensen af det matcher omkostningen af at estimere og alle de opdateringer af dem, der typisk ogs\u00e5 bruges ressourcer p\u00e5? Ogs\u00e5 hvis du indregner alle \u201dforbi\u2019erne\u201d.<\/p>\n
Hvordan kan vi g\u00f8re det anderledes<\/h4>\n
N\u00e5r vi arbejder p\u00e5 den agile m\u00e5de, bruger vi det at estimere ![\"\"](\"http:\/\/www.vilma-consulting.dk\/wp-content\/uploads\/2018\/01\/action-2277292_1920-1-300x205.jpg\")
ofte men med er ret lille tidsforbrug. En sprint planl\u00e6gnings session for et 2-ugers sprint tager omkring to timer, og end ikke al den tid er brugt p\u00e5 at estimere. Typisk er der 6-12 elementer der skal estimeres, og hver estimering tager fra 2-5 minutter<\/strong>. Ikke mere, men faktisk ofte mindre. Men bliver det pr\u00e6cist? Nej, egentlig ikke. Men det er ikke et problem, da det kommer til at passe i gennemsnit (og er du virkelig nysgerrig p\u00e5 det, s\u00e5 er der noget tung matematik der kan bevise det).<\/p>\nForskellen ligger i at bruge relativ estimering<\/strong> i stedet for absolut estimering, samt at angive v\u00e6rdien i en tidl\u00f8s enhed, som fx Story Points, eller hvad du har lyst til at kalde det. Estimaterne er specifikke for det team der har udf\u00f8rt dem, og kan bruges til dette teams fremskrivninger som fx hvor meget de kan levere af produktionsklart software p\u00e5 en sprint, n\u00e5r det bruges i kombination med den realiserede velocity (teamets hastighed i story points).<\/p>\nHvad er fordelene ved relativ estimering<\/strong><\/h4>\nDet er simpelt, hurtigt, omkostningseffektivt (hvad mere kan du \u00f8nske) og l\u00f8ser opgaven med at forudsige rimelig godt. Desuden aktiverer det hele teamet med at estimere, og leder derfor til mere velunderbyggede estimater. Sidst men ikke mindst, s\u00e5 kobles det at estimere med kvalificerende og opklarende sp\u00f8rgsm\u00e5l, s\u00e5ledes at mere detaljeret information overf\u00f8res fra rekvirent til teamet. I praksis er det information der ikke blev skubbet<\/em> fra rekvirenten men i stedet trukket <\/em>af teamet.<\/p>\nMen lige inden du sender hele dit estimeringsteam p\u00e5 porten, s\u00e5 er de stadig klart at foretr\u00e6kke hvis du byder p\u00e5 en opgave!<\/p>\n
Er der s\u00e5 nogen faldgruber ved at estimere relativt<\/strong><\/h4>\n\u2019There ain\u2019t no such thing as a free lunch\u2019. [Ukendt]\n
S\u00e5 ja, der er mere du skal vide. Men det er mindre og ganske rimelige ting, hvorefter du effektivt kan begynde at estimere relativt til fremskrivninger.<\/p>\n
\n- Det team der skal levere arbejdet, skal udf\u00f8re estimaterne. Dels fordi estimater ikke kan overf\u00f8res fra team til team. Men vigtigere er at teamet for v\u00e6sentlig information mens de estimerer.<\/li>\n
- Det er teamet \u2013 og ideelt alle p\u00e5 teamet \u2013 der estimerer. Der er ingen chefer (eller kl\u00f8gtige s\u00e6lgere) der skal p\u00e5virke estimaterne. Og egentligt ganske fair, da det er teamet der skal comitte<\/em> til at levere arbejdet og dermed den \u00f8nskede produktionsklare l\u00f8sning.<\/li>\n
- Adgang till information forud for, og mens teamet skal estimere, direkte fra kilden dvs. rekvirenten er helt centralt. Teamet skal hurtigt vurdere en opgave i forhold til andre, for at afslutte estimatet.<\/li>\n
- Respektfuldt samarbejde mens der estimeres. Uanset hvad der kommer op mens der estimeres, er bragt op af en grund. Og her er det b\u00e5de elementer der \u00f8ger estimatet og kendte genveje der s\u00e6nker estimaterne der er relevante.<\/li>\n
- Det at estimere relativt kan bruges operationelt, i visse sammenh\u00e6nge ogs\u00e5 taktisk men taber pusten f\u00f8r vi kommer til det strategiske niveau. Eller rettere, det kr\u00e6ver v\u00e6sentlig mere erfaring at f\u00e5 succes med det p\u00e5 dette niveau.<\/li>\n<\/ul>\n
Hvordan kommer jeg i gang<\/strong><\/h4>\nDet er nemt! Metoden kan forklares p\u00e5 2 minutter, og et team kan have l\u00e6rt det p\u00e5 en time. S\u00e5 det er desv\u00e6rre ikke her du kan finde begrundelsen for at du ikke kan\/vil begive dig ud i at estimere relativt. Og som altid, s\u00f8g efter videoer p\u00e5 nettet eller inddrag en agile specialist<\/a> for at komme nemt og sikkert I gang.<\/p>\nS\u00e5 alt taget i betragtning, s\u00e5 synes jeg det er et effektivt redskab som jeg gerne anbefaler. Lave omkostninger ved implementering, lave operationelle omkostninger, og rimelig kraftig prediktiv styrke ogs\u00e5 sammenlignet med traditionel estimering.<\/p>\n
<\/p>\n
Held og lykke med at komme i gang med relativ estimering!<\/p>\n
Majken Vildrik Thougaard<\/em><\/strong>, Uafh\u00e6ngig Agile Specialist & Ejer af VILMA Consulting<\/p>\nPS: <\/strong>Ikke at estimere (Not to estimate, no-estimate<\/em>) svarer i denne sammenh\u00e6ng alligevel til at estimere. Men p\u00e5 den indirekte m\u00e5de hvor alle opgaver i stedet skal v\u00e6re nogenlunde lige store, hvorefter det er tilstr\u00e6kkeligt at t\u00e6lle antallet af opgaver, for at kunne fremskrive. Dog kr\u00e6ver det et ret modent team at kunne f\u00e5 succes med i praksis.<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":"
Estimering er noget rigtig mange pr\u00f8ver at komme nemt om; som i helst slet ikke g\u00f8re. Eller f\u00e5 andre til at g\u00f8re for sig. Men hvorfor? At estimere ER et effektivt redskab n\u00e5r det kommer til at skaffe overblik og indsigt, hvis det bliver gjort smart. Og ja, der er selvf\u00f8lgelig mere end en m\u00e5de … <\/p>\n
Hvad skal estimater bruges til<\/strong><\/h4>\nHelt generelt bruges estimater til at forudsige noget p\u00e5 kortere eller l\u00e6ngere sigt. Men helt \u00e6rligt, hvorn\u00e5r har du sidst set en langsigtet prognose der rent faktisk ramte bulls eye? Det sker, bevares. Men mener du frekvensen af det matcher omkostningen af at estimere og alle de opdateringer af dem, der typisk ogs\u00e5 bruges ressourcer p\u00e5? Ogs\u00e5 hvis du indregner alle \u201dforbi\u2019erne\u201d.<\/p>\n
Hvordan kan vi g\u00f8re det anderledes<\/h4>\n
N\u00e5r vi arbejder p\u00e5 den agile m\u00e5de, bruger vi det at estimere ofte men med er ret lille tidsforbrug. En sprint planl\u00e6gnings session for et 2-ugers sprint tager omkring to timer, og end ikke al den tid er brugt p\u00e5 at estimere. Typisk er der 6-12 elementer der skal estimeres, og hver estimering tager fra 2-5 minutter<\/strong>. Ikke mere, men faktisk ofte mindre. Men bliver det pr\u00e6cist? Nej, egentlig ikke. Men det er ikke et problem, da det kommer til at passe i gennemsnit (og er du virkelig nysgerrig p\u00e5 det, s\u00e5 er der noget tung matematik der kan bevise det).<\/p>\nForskellen ligger i at bruge relativ estimering<\/strong> i stedet for absolut estimering, samt at angive v\u00e6rdien i en tidl\u00f8s enhed, som fx Story Points, eller hvad du har lyst til at kalde det. Estimaterne er specifikke for det team der har udf\u00f8rt dem, og kan bruges til dette teams fremskrivninger som fx hvor meget de kan levere af produktionsklart software p\u00e5 en sprint, n\u00e5r det bruges i kombination med den realiserede velocity (teamets hastighed i story points).<\/p>\nHvad er fordelene ved relativ estimering<\/strong><\/h4>\nDet er simpelt, hurtigt, omkostningseffektivt (hvad mere kan du \u00f8nske) og l\u00f8ser opgaven med at forudsige rimelig godt. Desuden aktiverer det hele teamet med at estimere, og leder derfor til mere velunderbyggede estimater. Sidst men ikke mindst, s\u00e5 kobles det at estimere med kvalificerende og opklarende sp\u00f8rgsm\u00e5l, s\u00e5ledes at mere detaljeret information overf\u00f8res fra rekvirent til teamet. I praksis er det information der ikke blev skubbet<\/em> fra rekvirenten men i stedet trukket <\/em>af teamet.<\/p>\nMen lige inden du sender hele dit estimeringsteam p\u00e5 porten, s\u00e5 er de stadig klart at foretr\u00e6kke hvis du byder p\u00e5 en opgave!<\/p>\n
Er der s\u00e5 nogen faldgruber ved at estimere relativt<\/strong><\/h4>\n\u2019There ain\u2019t no such thing as a free lunch\u2019. [Ukendt]\n
S\u00e5 ja, der er mere du skal vide. Men det er mindre og ganske rimelige ting, hvorefter du effektivt kan begynde at estimere relativt til fremskrivninger.<\/p>\n
\n- Det team der skal levere arbejdet, skal udf\u00f8re estimaterne. Dels fordi estimater ikke kan overf\u00f8res fra team til team. Men vigtigere er at teamet for v\u00e6sentlig information mens de estimerer.<\/li>\n
- Det er teamet \u2013 og ideelt alle p\u00e5 teamet \u2013 der estimerer. Der er ingen chefer (eller kl\u00f8gtige s\u00e6lgere) der skal p\u00e5virke estimaterne. Og egentligt ganske fair, da det er teamet der skal comitte<\/em> til at levere arbejdet og dermed den \u00f8nskede produktionsklare l\u00f8sning.<\/li>\n
- Adgang till information forud for, og mens teamet skal estimere, direkte fra kilden dvs. rekvirenten er helt centralt. Teamet skal hurtigt vurdere en opgave i forhold til andre, for at afslutte estimatet.<\/li>\n
- Respektfuldt samarbejde mens der estimeres. Uanset hvad der kommer op mens der estimeres, er bragt op af en grund. Og her er det b\u00e5de elementer der \u00f8ger estimatet og kendte genveje der s\u00e6nker estimaterne der er relevante.<\/li>\n
- Det at estimere relativt kan bruges operationelt, i visse sammenh\u00e6nge ogs\u00e5 taktisk men taber pusten f\u00f8r vi kommer til det strategiske niveau. Eller rettere, det kr\u00e6ver v\u00e6sentlig mere erfaring at f\u00e5 succes med det p\u00e5 dette niveau.<\/li>\n<\/ul>\n
Hvordan kommer jeg i gang<\/strong><\/h4>\nDet er nemt! Metoden kan forklares p\u00e5 2 minutter, og et team kan have l\u00e6rt det p\u00e5 en time. S\u00e5 det er desv\u00e6rre ikke her du kan finde begrundelsen for at du ikke kan\/vil begive dig ud i at estimere relativt. Og som altid, s\u00f8g efter videoer p\u00e5 nettet eller inddrag en agile specialist<\/a> for at komme nemt og sikkert I gang.<\/p>\nS\u00e5 alt taget i betragtning, s\u00e5 synes jeg det er et effektivt redskab som jeg gerne anbefaler. Lave omkostninger ved implementering, lave operationelle omkostninger, og rimelig kraftig prediktiv styrke ogs\u00e5 sammenlignet med traditionel estimering.<\/p>\n
<\/p>\n
Held og lykke med at komme i gang med relativ estimering!<\/p>\n
Majken Vildrik Thougaard<\/em><\/strong>, Uafh\u00e6ngig Agile Specialist & Ejer af VILMA Consulting<\/p>\nPS: <\/strong>Ikke at estimere (Not to estimate, no-estimate<\/em>) svarer i denne sammenh\u00e6ng alligevel til at estimere. Men p\u00e5 den indirekte m\u00e5de hvor alle opgaver i stedet skal v\u00e6re nogenlunde lige store, hvorefter det er tilstr\u00e6kkeligt at t\u00e6lle antallet af opgaver, for at kunne fremskrive. Dog kr\u00e6ver det et ret modent team at kunne f\u00e5 succes med i praksis.<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":"
Estimering er noget rigtig mange pr\u00f8ver at komme nemt om; som i helst slet ikke g\u00f8re. Eller f\u00e5 andre til at g\u00f8re for sig. Men hvorfor? At estimere ER et effektivt redskab n\u00e5r det kommer til at skaffe overblik og indsigt, hvis det bliver gjort smart. Og ja, der er selvf\u00f8lgelig mere end en m\u00e5de … <\/p>\n
ofte men med er ret lille tidsforbrug. En sprint planl\u00e6gnings session for et 2-ugers sprint tager omkring to timer, og end ikke al den tid er brugt p\u00e5 at estimere. Typisk er der 6-12 elementer der skal estimeres, og hver estimering tager fra 2-5 minutter<\/strong>. Ikke mere, men faktisk ofte mindre. Men bliver det pr\u00e6cist? Nej, egentlig ikke. Men det er ikke et problem, da det kommer til at passe i gennemsnit (og er du virkelig nysgerrig p\u00e5 det, s\u00e5 er der noget tung matematik der kan bevise det).<\/p>\nForskellen ligger i at bruge relativ estimering<\/strong> i stedet for absolut estimering, samt at angive v\u00e6rdien i en tidl\u00f8s enhed, som fx Story Points, eller hvad du har lyst til at kalde det. Estimaterne er specifikke for det team der har udf\u00f8rt dem, og kan bruges til dette teams fremskrivninger som fx hvor meget de kan levere af produktionsklart software p\u00e5 en sprint, n\u00e5r det bruges i kombination med den realiserede velocity (teamets hastighed i story points).<\/p>\n Det er simpelt, hurtigt, omkostningseffektivt (hvad mere kan du \u00f8nske) og l\u00f8ser opgaven med at forudsige rimelig godt. Desuden aktiverer det hele teamet med at estimere, og leder derfor til mere velunderbyggede estimater. Sidst men ikke mindst, s\u00e5 kobles det at estimere med kvalificerende og opklarende sp\u00f8rgsm\u00e5l, s\u00e5ledes at mere detaljeret information overf\u00f8res fra rekvirent til teamet. I praksis er det information der ikke blev skubbet<\/em> fra rekvirenten men i stedet trukket <\/em>af teamet.<\/p>\n Men lige inden du sender hele dit estimeringsteam p\u00e5 porten, s\u00e5 er de stadig klart at foretr\u00e6kke hvis du byder p\u00e5 en opgave!<\/p>\n \u2019There ain\u2019t no such thing as a free lunch\u2019. [Ukendt]\n S\u00e5 ja, der er mere du skal vide. Men det er mindre og ganske rimelige ting, hvorefter du effektivt kan begynde at estimere relativt til fremskrivninger.<\/p>\n Det er nemt! Metoden kan forklares p\u00e5 2 minutter, og et team kan have l\u00e6rt det p\u00e5 en time. S\u00e5 det er desv\u00e6rre ikke her du kan finde begrundelsen for at du ikke kan\/vil begive dig ud i at estimere relativt. Og som altid, s\u00f8g efter videoer p\u00e5 nettet eller inddrag en agile specialist<\/a> for at komme nemt og sikkert I gang.<\/p>\n S\u00e5 alt taget i betragtning, s\u00e5 synes jeg det er et effektivt redskab som jeg gerne anbefaler. Lave omkostninger ved implementering, lave operationelle omkostninger, og rimelig kraftig prediktiv styrke ogs\u00e5 sammenlignet med traditionel estimering.<\/p>\n <\/p>\n Held og lykke med at komme i gang med relativ estimering!<\/p>\n Majken Vildrik Thougaard<\/em><\/strong>, Uafh\u00e6ngig Agile Specialist & Ejer af VILMA Consulting<\/p>\n PS: <\/strong>Ikke at estimere (Not to estimate, no-estimate<\/em>) svarer i denne sammenh\u00e6ng alligevel til at estimere. Men p\u00e5 den indirekte m\u00e5de hvor alle opgaver i stedet skal v\u00e6re nogenlunde lige store, hvorefter det er tilstr\u00e6kkeligt at t\u00e6lle antallet af opgaver, for at kunne fremskrive. Dog kr\u00e6ver det et ret modent team at kunne f\u00e5 succes med i praksis.<\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" Estimering er noget rigtig mange pr\u00f8ver at komme nemt om; som i helst slet ikke g\u00f8re. Eller f\u00e5 andre til at g\u00f8re for sig. Men hvorfor? At estimere ER et effektivt redskab n\u00e5r det kommer til at skaffe overblik og indsigt, hvis det bliver gjort smart. Og ja, der er selvf\u00f8lgelig mere end en m\u00e5de … <\/p>\nHvad er fordelene ved relativ estimering<\/strong><\/h4>\n
Er der s\u00e5 nogen faldgruber ved at estimere relativt<\/strong><\/h4>\n
\n
Hvordan kommer jeg i gang<\/strong><\/h4>\n