Estimations and planning (agile/scrum)

Collaboration, product, and users

Estimations and planning (agile/scrum)

Hur många story points tycker du att vi ska ge den här biljetten?

Jag känner att vi nog underskattade hur komplex den här uppgiften faktiskt var.

Det här känns som en typisk trea, den bör gå ganska snabbt att lösa.

Jag lägger en åtta på den här, för det är otroligt många okända faktorer involverade.

Vi hinner absolut inte få in den här funktionen i den pågående sprinten.

Vad tror ni om vår 'velocity' (hastighet) inför den här sprintplaneringen?

Kan vi flytta den där uppgiften till nästa sprint istället, vi har tagit på oss för mycket.

Den här användarberättelsen (user storyn) är alldeles för stor, vi måste bryta ner den.

Vi behöver nog ta ett 'spike'-ärende (undersökningsuppgift) innan vi kan estimera detta ordentligt.

Låt oss köra en runda 'planning poker' för att sätta poäng på de sista biljetterna.

Min bedömning är att det här kommer att ta ungefär två till tre heldagar att bygga.

Jag röstade högre eftersom jag tror att integrationen med det gamla systemet kommer strula.

Sprintmålet för den här veckan är att få klart hela det nya inloggningsflödet.

Vi har glömt att planera in tid för kodgranskning (code review) och testning.

Jag är redan fullbokad den här sprinten, så någon annan måste nog ta den biljetten.

Det är svårt att estimera tiden när acceptanskriterierna är så extremt otydliga.

Ska vi boka in 'backlog refinement' (förfining av backloggen) på torsdag eftermiddag?

Vi måste planera in en liten tidsbuffert för alla oförutsedda buggar och möten.

Jag tycker att vi överlag är ganska bra på att hålla de tidsramar vi sätter upp.

Om vi sätter en femma på den här uppgiften, vem känner sig bekväm med att ta den?

Vårt team har tyvärr bränt ut sig (burnout) lite på sistone, vi måste sänka tempot.

Burndown-chartet ser väldigt bra ut, vi ligger precis i fas för att bli klara på fredag.

Hur mycket kapacitet har vi egentligen kvar i teamet med tanke på att två är sjuka?

Kan vi prioritera de tekniska skulds-biljetterna lite högre upp i nästa sprintplanering?

Detta är ett extremt kritiskt ärende, så vi får behandla det som en 'expedite' (gräddfil).

Jag är tyvärr blockerad, så jag kan inte bidra till vårt sprintmål idag.

Vi brukar generellt räkna med att en story point motsvarar ungefär en halv arbetsdag.

Låt oss inte planera in mer än åttio procent av vår teoretiska maxkapacitet.

Jag tycker vi ska ha som regel att aldrig estimera i timmar, bara i story points.

Det är en extremt enkel fix, jag sätter en etta på den och plockar den direkt efter lunch.

Vi var helt fel ute i våra estimat förra sprinten, vad kan vi lära oss av det på retrospektivet?

Ska vi ta en snabb stand-up nu och se om någon behöver hjälp för att stänga sina uppgifter?

Vi kan släppa design-biljetten nu, den har blockerats i två sprintar redan.

Uppgiften är mycket större än vad den ser ut vid en första anblick.

Det är bättre att överskatta tiden och leverera tidigt, än att lova för mycket och missa.

Jag tror vi måste dra tillbaka biljetten till backloggen tills designen är helt spikad.

Jag tar rollen som Scrum Master under de kommande två veckorna medan han är på semester.

Låt oss göra en 'definition of ready' (DoR) innan vi drar in fler luddiga uppgifter.

Jag har redan skapat alla 'sub-tasks' (underuppgifter) som behövs för den här storyn.

Vi behöver nog ta hjälp av ett annat team om vi ska klara den här deadlinen.

Kan vi lägga in lite 'slack time' (luft i schemat) för kompetensutveckling och labbande?

Den här biljetten är en återkommande huvudvärk, vi måste lösa grundproblemet snart.

Vad säger ni, är vi helt överens om att fem är ett rimligt estimat för hela gruppen?

Den där uppgiften känns som ett 'epic' snarare än en vanlig story, den tar månader.

Jag är lite orolig över antalet poäng vi drar in, vi har aldrig klarat så mycket förut.

Om alla är färdiga med sina uppgifter, kan vi börja dra in saker från nästa sprint?

Det här projektet drivs med Kanban istället för Scrum, vilket passar supportflödet mycket bättre.

Vi måste säkerställa att testarna också har tid att titta på uppgiften innan sprinten är slut.

Ett bra estimat bygger på erfarenhet, och vi blir bättre och bättre på det för varje vecka.

Mötet drog ut på tiden, men vi har åtminstone en väldigt solid och trygg plan framåt nu.